I too would be interested in knowing how the CLONE_PID stuff is
supposed to work. Has it been written down, or whenabouts was it
discussed? Is it being worked on, and if so how is it progressing?
> The other feature of LWPs, that has been lost in this discussion, is
> that multiple threads are scheduled upone a single LWP. In
> traditional Solaris, it allocates LWPs sparsely. The only reason to
> do a 1:1 binding, or specify a binding, is that LWPs are the
> entities block on system calls. As long as you're not calling any
> calls that could block, LWPs can efficiently schedule threads. This
> is advantageous in that thread creation is REALLY inexpensive,
> because it doesn't create a new LWP every time. I think that this
> is the secret to an appropriate thread implmentation thats
> "lightweight".
Yes, you could do a user-space thread implementation on Linux where a
number of user-space threads are mapped to a smaller number of
clone()-based threads. I don't think that any more kernel support is
required to do this, although the completion of CLONE_PID (and
whatever else is needed for full POSIX threads compliance) would
help. This approach also has problems getting all the syscalls to work
as required (especially the SysV IPC ones).
(On a vaguely related topic, I heard someone was implementing the
POSIX.1b asynchronous IO stuff. What are they adding to the kernel to
do this?)
I'm hoping that at some point there will be enough support in the
kernel so that LinuxThreads can have a pthread_create() that mostly
consists of a clone(). Possibly that is intended to be part of
CLONE_PID; this is one of the reasons why I'd like to know the shape
CLONE_PID is supposed to take.
Other than pthread_create(), I don't think that there are performance
problems in LinuxThreads, and even that is good enough for most
applications today. So I agree with Ulrich Drepper: POSIX threads
compliance should be the first goal, and attaining the
more-than-adequate performance levels we're used to with Linux should
be secondary.
-- Dave Wragg- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu