DragonFly kernel List (threaded) for 2003-07
Re: userapi: signals
:Hmmm... the kernel would at least have to be aware of userland threading
:for processes that are threaded across multiple CPUs, no?
That's what rfork() is for.
:I would have thought that the ideal would be that userland threading and
:kernel threading are really the same thing, like kernel and userland
:messages. Or am I just missing something obvious?
Memory overhead and efficiency. From a theoretical viewpoint it
never makes sense to have more then NCPU kernel threads dedicated
to a user program, regardless of how many userland threads that
user program is running. The only reason 1:1 models are so popular
is because most kernels block synchronously and it is simply more
convenient to give each user thread a kernel thread equivalent in
When we are through we are not going to be blocking synchronously in
system calls (or VM faults either, eventually).
So our model will be to rfork() to cover available cpus, asynchronous
syscalls, and perhaps an upcall to allow a thread switch to occur
when a vm fault blocks. Believe me I am not making things easier for
us in kernelland by putting the burden on userland, achieving the
asynch syscall goal is going to be plenty difficult!