DragonFly kernel List (threaded) for 2003-07
Re: userapi: signals
:> 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.