On Tue, 8 Nov 2005 10:13:53 +0100 Joerg Sonnenberger <[EMAIL PROTECTED]> wrote:
> > Other than the memory exhaustion Matt mentions, it is also about atomicy > of process context state. A lot of the kernel depends on the UID not > changing over time during a system call. sendsys breaks this and other > assumptions from the single syscall modell. Ok, please bear with me as I am new to the DragonFly system, but this does not quite make sense to me. sendsys shouldn't introduce any new concurrency issues. All it does is allocate a sysun and fill in the message structure, and then dispatch to the syscall using a function pointer. It specifically does not try to find a service thread or do any queueing or scheduling, and that is IMHO a highlight of the design. In fact, sendsys is really quite like syscall currently. The major differences are the different parameter passing convention and that sendsys allows (but does not require) an EASYNC return. BTW, the EASYNC return seems to pass a kernel address back as the error code. The big departure for sendsys is when it will start interpreting the 'port' parameter to allow a user process access to multiple kernel/user subsystems, and using lwkt_beginmsg() to act as a standard LWKT message source. But even this shouldn't have concurrency implications, because it is still up to each individual subsystem (via how it sets up its ports) to determine whether it runs the request synchronously in the thread of the caller or otherwise. So, as we transition systems to use the service thread model, that seems to me to be the ideal time to go through and make sure that those systems can handle letting other code run when they relinquish control. If there is code that has already been EASYNC-ized that is still implicitly assuming that it monopolizes the thread of its caller when it runs its requests, I would like to go through and fix those systems. Any hints would be greatly appreciated. Thanks again. -Eric
