Re: userapi: signals

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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
    that case.

    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!

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>