Re: userapi: signals

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

Matthew Dillon  wrote:
>    I'm not sure how much kernel threading applies to user threading.  Kernel
>    threads are more sensitive to memory issues since there is only one 
>    KVM address space and very little of it is pageable.

That doesn't mean the one can't be modelled on the other, and there's a
lot of reasons (including the ease of developing code that can run in
both contexts) for modelling the one on the other.

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

>    No.  In userland anything can happen.  The system is free to interrupt
>    a userland program and migrate it to another cpu at any time.

OK, for "CPU" read "virtual CPU". It's going to continue to share its
kernel-managed execution context with the same set of threads, and
within that context it won't be preempted unless a signal (the user
level equivalent of an interrupt) occurs.

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

>    The rfork()'d 'process' that a userland thread is running on is under the
>    complete control of the userland thread scheduler (or will be when this
>    baby is written!).  This means that you can do whatever you want... you
>    can create a per-rfork memory area and access it like a kernel thread
>    would access its own per-cpu area, without locking.

The reasons for doing so in the kernel also apply in the userland, though,
so the well reasoned arguments for having such per-hardware-context data
in the kernel apply to having the same per-rfork-context data in userland.

It may not be very large, processes can be much simpler then the kernel,
but at the very least it's going to need to have a system message port and
a reply port in it, and whatever long term context the UNIX syscall emulator
needs.

>:	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).

>    To another abstracted cpu (rfork).  Yes, though perhaps all it really
>    needs to do is write() to a communications pipe that goes to the target
>    (abstracted) cpu.  Thus this sort of operation would become more
>    efficient under heavier loads.

That write() is probably going to require a context switch through kernel
mode to complete (if only to avoid race conditions), though like an IPI that
context switch can be deferred if there's other work still to do in the current
rfork()ed context, and bundled up with other work.

If you have a consistent view of memory AND you know for sure the other
thread's on another CPU you could probably get away with something
like a spinlock (but if it's on the same CPU that could get expensive :) ).

>    Right.  In fact, we could probably compile most of the LWKT subsystem
>    separately as part of the userland scheduler. 

Whether it's the same code or not (and that would be cool) it has a lot of
the same restrictions and responsibilities.

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

>    Probably.  There are lots of ways to do this.

And it would probably be a good idea to be able to select different
models in different situations. Almost all the time it would be far more
safer and far more efficient to have signals occur synchronously when
you hit a Wait()... and whether you do or not it would possibly be
necessaryΒ to run them in a separate thread... otherwise it gets hard to
figure out how to interleave their calls to the system call emulator with
the mainline's calls.

Do this right, and the UNIX system call emulator itself could run in the
kernel. Which opens up all kinds of interesting possibilities. It would
probably become possible to port dragonfly to hardware that doesn't
even have an MMU, like an Amiga 1000 or Palm III.