userapi: signals

[Matthew Dillon]

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

   Oh, absolutely.  In fact I expect it ought to be possible to transplant
   most of the LWKT scheduler and LWKT messaging code to userland.

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

    Correct.  So the same abstractions we use in the kernel could be used
    in userland.  i.e. messaging between (rforked) processes, use of a
    'critical section' to protect per-(rfork)-cpu data, localized scheduling,
    and so forth.

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

    There are lots of ways to do this.  Perhaps the use of a pipe just for
    notification (e.g. just write one byte and read-drain), or a SysV
    semaphore, and transfer the messages directly via shared memory.

    The kernel uses a very interesting lockless cross bar mechanism to
    handle the IPI messaging between cpus.  See lwkt_send_ipiq() in
    kern/lwkt_thread.c.  That sort of mechanism could easily be applied
    to the userland scheduler as well for communication between cpus.

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

    I really want the syscall emulator to run in usermode because the
    syscall emulator has so many interesting possibilities that only
    the ease of userland development (not crashing the system :-)) is
    capable of realizing them all.  Also because the emulation layer can
    become quite complex, especially considering linux and sysv (which I
    want to move out of the kernel and into the emulation layer), and 
    moving it out of the kernel would make the system more stable without
    costing us any performance.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>