userapi: signals

[Peter da Silva]

>     There are address space issues still... UNIX depends on fork() and a
>     traditional fork() is not possible in kernel space.

fork() is always going to be a problem. If fork() just creates a thread and
stalls the original until it calls exec() (sort of a baby step beyond vfork())
userapi could stretch to cover most situations. Given that exec() will be
cheap by comparison with exec in userland (allocate a new userapi per-thread
structure, allocate a globals table and copy it... kind of like a PalmOS
launch) implementing pseudo-rfork and pseudo-vfork only should cover it...