Alexander was talking about FreeBSD's user-level threads, though.
> Kernel threads isn't even an option for the >50,000 threads I have in
> mind. I'm not talking about being silly with threads here for the sake
> of it. I'm talking about having >50,000 objects in a simulation, which
> most of the time don't need a locally allocated stack or kernel context.
> However, occasionally they do need one (when they block, or page to
> disk).
Fine, but if you are talking about threads (of any kind) that don't
have individual stacks, then it doesn't have much bearing on
pthreads. Such threads are very interesting in their own right, though.
> The intention is (1) that a typical fast "schedule calling 50,000
> objects' `think()' methods" list+heap scheduler runs most of the objects
> efficiently (without individual stack frames); (2) some processing
> continues even while paging;
Your sleeping-process-signals-another-process idea gives this, and is
easy to implement. (And possibly could be used for a nice
implementation of POSIX aio).
> (3) a few objects can use operating system
> services and get their own stack frame (on demand), while being able to
> use the same mutex/semaphore/message services as the 50,000 simulated
> objects.
I can see why you would want this. But why should a pthreads
implementation provide mutex, etc. facilities that can be used by
programs well outside the scope of pthreads? If you can do it in
LinuxThreads with no significant cost to other LinuxThreads progams,
go ahead. But if you can't, then it's not going to be attractive to
people doing things that don't resemble heavily-threaded simulations.
Dave Wragg
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/