Re: userapi: signals

[Peter da Silva <peter-dragonfly@xxxxxxxxxxx>]

Matthew Dillon wrote:
> :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.

OK, but that's what it's like in the kernel as well, isn't it? Kernel 
threads are a lightweight per-cpu concept, really, with synchronization 
between them being deferred to the more expensive IPI token passing...

So...

Maybe I'm confused or I'm not presenting myself well. Let me see if I 
can get this straight. We can draw some parallels...

	1a. Each cpu in the system has its own self-contained LWKT scheduler.

	1b. Each process in user mode has its own self-contained userland 
thread scheduler.

	2a. A Thread will never be moved to another cpu while it is running, 
and a thread will never be preemptive switched to a non-interrupt thread.

	2b. A userland thread will never be moved to another CPU, and will 
never be preempted by a non-signal thread.

	3a. A Thread can access non-global information without having to obtain 
any locks...

	3b. A userland thread can access non-global information without having 
to make any system calls...

	4a. A cpu which attempts to schedule a thread belonging to another cpu 
will issue an IPI-based message to the target cpu to execute the operation.

	4b. A userland thread which attempts to schedule a thread belonging to 
another CPU will make a system call (or send a message through a 
non-system kernel message port).

None of this means the kernel needs to know about userland threads, it 
just means that the userland thread code is acting like the kernel 
thread code. So the userland process gets a signal and it schedules the 
signal thread... my question is more along the lines of:

Can a process request a signal to fire when a message arrives on one of 
its kernel message ports, in which case it would be able to support 
preemptive signals, or would it have to wait for the signal to arrive on 
its reply port, in which case signal handlers (or the signal thread) 
would have to be scheduled synchronously when a Wait() occurs.