Sorry, I haven't, but this thread (tongue-n-cheek) is the place that
I got on, also, I wasn't subbed to the list then. I emailed Linus
a long time ago, once I heard clone was available, and suggested
kernel threads. He replied that kernel threads wouldn't make SMP
any faster (that was the context of the conversation). I see 'kernel
threads' (and implementation of generic LWPs + processes) as a good
addition now.
> we started discussing this before the kernel had the clone syscall)
> you know that this always was a proposed method. I once wrote a
> proposal to follow the model used on Mach systems using upcalls).
> This model mixes kernel and user-level threads to get the best of both
> worlds.
>
> The problem is that this is complicated and it requires more kernel
> changes. E.g., delivering a signal to a specific thread, how do you
> want to do this if the kernel does not know about the entities? I
The LWP would have a signal mask. Any thread that calls signal functions
would automatically be bound to 1 LWP, and that LWP would have only 1
thread scheduled on it. The LWP would have the signal mask. When a
process got a signal, it would walk the list of LWPs assigned to it, and
deliver the signal to the appropriately masked LWPs.
> solution is to open the kernel by keeping the process/thread/clone
> specific data partly in user-level but you can imagine how problematic
> this is.
If you utilized LWPs, you don't need to make the guts in the user space.
Any thread libraries would just be implemented on top of LWPs, in user
space. There would be 1 LWP for the thread management. And the threads
would be scheduled on LWPs per it's scheduling policy. The sigmask and
such would remain kernel entities, but modifiable and probeable via
userspace.
>
>
> The alternative to all this is that you have compliant POSIX threads
> based on clone() and another library implementing LWP which are not
> POSIX compliant threads. Approaches like this exist and you are free
> to use them.
Of course, but the issue I'm making is that LWPs would make extension of
the kernel more cleanly implemented in this area. Clone() is a hack of
sorts, and it has a high system overhead. It is far from being a superior
solution to Solaris.
>
> -- Uli
Don't get me wrong, I'm not suggesting a mass suicide, I'm merely suggesting
that making a generic, abstract, kernel level process interface that doesn't
incurr a serious overhead, and has a really good, extensible API is a good thing.
Clone() also suffers from a signal issue. Linux does not conform to the posix
way of doing threads when it comes to signal. In posix, you're supposed to launch
a thread to wait for a signal for the process. With clone() a thread gets
signals independent of the process, this is bad(tm) and precludes me from really
suggesting MT on Linux at work (I can't suggest something that would require
oddball hacks to work).
My $0.02,
--Perry
-- Perry Harrington Linux rules all OSes. APSoft () email: perry@apsoft.com Think Blue. /\- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu