Userland threading and messaging

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

Hi all,
after a restless night I had some thought about the userland
threading. First let's recall our current infrastructure:
a) the old synchronous syscall interface
b) the new asynchronous sysmessage interface
c) LWP aka virtual CPUs
d) signal trampoline code.

IMO we want to drop a) and work much like the old MIT (?) pthread
implementation entirely in userspace. Therefore we have a process
most if not all syscalls / messages asynchronous. The scheduling
and esp. the handling of different userland threads needs some
context switching which could be copied from the kernel. The
signal code could be reused as upcall mechanism to notify the
process about POSIX signals, finished messages or want ever we
want. That's all fine.

ATM I can't see how the userland could send two asynchronous
nanosleep messages and differenciate the two results. I could
use two message ports but this leads to the other problems
(polling). Could be add some kind of tag to every message which
is passed in by the caller and returned to him? This would be
enough to identify e.g. the userland thread from which the
message orignated or an even finer grained model. I think a
pointer would be best for such a tag.

Now the next problem: Outstanding messages on process death. 
That means core dump, exit(3) and exec(3). We
have ATM the following types of syscalls/messages:
- IO and network message -> long term
- process and security -> mostly short term
- time -> long term
- ...
The first category is problematic and needs support for a revoke operation.
This would be handled entirely within the network or VFS layer.
The second category is uncritical since we might end up implementing
them mostly synchronous otherwise let them use the zombie. We need
some userland handling for fork to flush all queues, which should not
be duplicated (?). The time messages like nanosleep should be revokable
anyway.

Joerg