The US was actively helping Ho Chi Minh's people with the aim of stopping them from becoming communists when they became more organised after the war, until French interests killed the "American man on the ground" in an ambush (I forget his name) which closed the channel between the State/Foreign dept. and the Viet Minh, who then turned communist in reality to get help from the Russians instead.
(you are in a maze of twisty little passages all alike)
The maximum speed of spaceshipOne was about
3000 MpH, but to get into orbit you need about
(from memory) something like 15000 MPH.
that's 5 times as fast.. from basic physics,
you need 25 times the energy (*). And that doesn't
include the energy needed to accelerate the
extra fuel...
SpaceshipOne is a nice toy but it's not going to help in real problems such as getting stuff into orbit. That takes a whole extra order of magnitude
of effort. It'd be nice if the prize led to somone
figuring out how to get around THAT problem..
(*) Most low orbits seem to be about 90+ minutes for a 24,000 mile circumference..
A higher orbit can travel slower, but you need more fuel to get higher....
I guess spaceshipOne might be able to get a 50g
package into orbit if it had a linear accelerator or something strapped to it and shot it out at 15000 Mph in the right direction.. but even that'd
be pretty damned heavy.
Well, thanks for asking...
We chose M:N because with scheduler activations it wasn't really a very difficult thing to do.
And we came from a culture of trying to not use kernel resources for everything..
We have the option of running in 1:1 mode or in
M:N mode with the same code, and we can support 30,000
or so threads in userspace (depending on tuning)
and not use 30,000 ses of kernel resources.
As I mentionned in another response, The code we ended up with can run in both 1:1 and M:N modes and the library can be compiled to operate in either mode.
To be fair, we took a long time to do this and SUN
changed thir minds on the topic when we had already decided where to go, but either way
we have good threads..
It really is quite cute to hit 'H' in top and see Mozilla split into 3 threads..
We have quite a bit of cleaning up to do..
for example the cpu affinity is mostly a fiction at this time, (at least between threads) and the
scheduler interractiosn need work..
As I have pointed out.. what we implemented was t thread framework that can be used to implement almost any threading model..
For example we will be able to emulate linux threads (well, we do in linux mode) but linux
will not be able to emulate our threading unless they add SAs to their kernel..
We can do:
* process based (clone) threading (e.g. linuxthreads)
* process internal threads (the old single process threads)
* 1:1 system scope threads
* 1:1 process scope threads
* M:N theads with async syscalls. (SAs)
We'll see which survives in 5 years:-)
Hopefully this makes a good platform for people
to do thread research.. That was a big design
goal.. provide general solutions that people can
use their imagination to use in ways we hadn't thought of..
That's where libthr came from.. it was a surprise to us.. people whipped it up in a few weeks
using the infrastrucure we'd made.
(they didn't know how close we were to releasing
working code so their stopgap and kse were released almost together:-)
This is a simplification.. KSE is not just M:N but also 1:1
The code to generate new "kernel threads" on the fly if an existing thread blocks is only a small part of what was done (though it was tricky I admit).
Re: KSE and 1:1 vs M:N, It can be used in either way. firstly the library can be compiled to create a separate kernel thread for each user thread, and secondly, the thread creation process can be done in a way that guarantees a kernel thread bound to the new thread. even if the library was compile "M:N".
libthr is another arrow in the quither, but libkse (as it was called) can do most that libthr can do. (I think the kernel supported mutex that libthr can use is probably more efficient than what libkse uses for the same thing (but I haven't benchmarked them)
Slashdot Mirror
Dear Mr Kerry and Mr Bush,
Can you please include the names of your advisers that played a part in answering these questions.
The US was actively helping Ho Chi Minh's people with the aim of stopping them from becoming communists when they became more organised after the war, until French interests killed the "American man on the ground" in an ambush (I forget his name) which closed the channel between the State/Foreign dept. and the Viet Minh, who then turned communist in reality to get help from the Russians instead. (you are in a maze of twisty little passages all alike)
SpaceshipOne is a nice toy but it's not going to help in real problems such as getting stuff into orbit. That takes a whole extra order of magnitude of effort. It'd be nice if the prize led to somone figuring out how to get around THAT problem..
(*) Most low orbits seem to be about 90+ minutes for a 24,000 mile circumference.. A higher orbit can travel slower, but you need more fuel to get higher....
I guess spaceshipOne might be able to get a 50g package into orbit if it had a linear accelerator or something strapped to it and shot it out at 15000 Mph in the right direction.. but even that'd be pretty damned heavy.
I want Arthur.C.Clark's space elevator dammit!
We have the option of running in 1:1 mode or in M:N mode with the same code, and we can support 30,000 or so threads in userspace (depending on tuning) and not use 30,000 ses of kernel resources.
As I mentionned in another response, The code we ended up with can run in both 1:1 and M:N modes and the library can be compiled to operate in either mode.
To be fair, we took a long time to do this and SUN changed thir minds on the topic when we had already decided where to go, but either way we have good threads..
It really is quite cute to hit 'H' in top and see Mozilla split into 3 threads..
We have quite a bit of cleaning up to do.. for example the cpu affinity is mostly a fiction at this time, (at least between threads) and the scheduler interractiosn need work..
As I have pointed out.. what we implemented was t thread framework that can be used to implement almost any threading model.. For example we will be able to emulate linux threads (well, we do in linux mode) but linux will not be able to emulate our threading unless they add SAs to their kernel..
We can do:
* process based (clone) threading (e.g. linuxthreads)
* process internal threads (the old single process threads)
* 1:1 system scope threads
* 1:1 process scope threads
* M:N theads with async syscalls. (SAs) We'll see which survives in 5 years :-)
Hopefully this makes a good platform for people to do thread research.. That was a big design goal.. provide general solutions that people can use their imagination to use in ways we hadn't thought of.. That's where libthr came from.. it was a surprise to us.. people whipped it up in a few weeks using the infrastrucure we'd made. (they didn't know how close we were to releasing working code so their stopgap and kse were released almost together :-)
This is a simplification..
KSE is not just M:N but also 1:1
The code to generate new "kernel threads" on the fly if an existing thread blocks is only a small part of what was done (though it was tricky I admit).
Re: KSE and 1:1 vs M:N,
It can be used in either way.
firstly the library can be compiled to create a separate kernel thread for each user thread,
and secondly, the thread creation process can be done in a way that guarantees a kernel thread bound to the new thread. even if the library was compile "M:N".
libthr is another arrow in the quither, but
libkse (as it was called) can do most that libthr
can do. (I think the kernel supported mutex that
libthr can use is probably more efficient than what libkse uses for the same thing (but I haven't
benchmarked them)