> > 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
If you implement threads in userspace, signals is a REALLY BAD way of
doing context switches. Is it possible for an LWP to register a routine
to be called on a OS context switch? Each process has a quantum of 200ms
(according to sources on the list), slicing this 200ms accross LWPs
(clone() threads) and letting each thread know when a context switch has
ocurred would make userspace context switching trivial. So, instead of
using signals and timers, is there an asynchronous way of letting an LWP
know when it has continued from a context switch? Say, every 5th context
switch, we schedule a different thread...moving the last thread to the
bottom of the queue, this would also allow for a pthread_yield() to work
more efficiently.
> 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).
>
[SNIP]
>
> Dave Wragg
>
--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