Date: Thu, 07 Mar 2002 17:24:16 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Jeff Roberson <jroberson@chesapeake.net> Cc: bright@mu.org, julian@elischer.org, arch@freebsd.org Subject: Re: Contemplating THIS change to signals. (fwd) Message-ID: <3C8812C0.DE9060FB@mindspring.com> References: <20020307195241.M64788-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Jeff Roberson wrote: > > Both Poul-Henning Kamp and Nate Williams bring up the important > > point of potentially long running syscalls, there are two > > ways you might consider fixing this: > > > > 1) add an additional flag to msleep to allow suspension during sleep. > > 2) restart the syscall at the userland boundry. > > Wouldn't it be reasonable to ignore the stop until we return to the user? > This way we could continue to honor all other signals inside msleep, which > seems to be very desirable. We should just postpone the STOP until we > actually return to the user. > > Am I missing something? A long running system call is supposedly signallable; in the STOP case, this implies that it pauses operation ubtil a CONT or a subsequent interrupt. As Julian has noted, "STOP" is a special case. Doing it your way, you would continue to send data on a "sendfile" operation; doing it the old way, the operation is suspended. In theory, according to the most recent postings by Julian, Julian's change will not modify the behaviour. But instead will cause the run-up to the user boundary, instead of in the middle of wherever the signal was delivered. For things like STOP, this means that it will run up to the user boundary. I'm not sure this is right, if there is a subsequent CONT; for an interrupt, Julian is correct that there is no visible difference in running it up to the user boundary, vs. doing a wakeup as a result, and later scheduling the runnning up to the user boundary; see my prior posting, and Nate's prior posting. Julian's point is that this will make things easier for the KSE work. THis is because it can use a KSE context to do the run up to the user boundary, rather than having to be a special case, where the processor continues the next time the process is scheduled (in this case the KSE), to do the runnning up then. The benefit to doing this for the KSE case should be obvious: it decouples the scheduling from the KSE itself having to run to completion (or at least the user boundary). This means that the priority for the signal delivery can be arbitrated by the user threads scheduler, which gives it more control than it would have otherwise, and saves some masking and unmasking. I'm personally really leery of changes in this area, since I expect at some time that there will be desire to support POSIX queued signals as part of the RT POSIX extensions (a recent discussion about signal delivery in aio completion events indicates that this may be an immediate need for an application being ported from Linux). I'm also a little bit leery, since by the same argument that Julian is using, signals can be delivered to user space in the KSE case, to be dispatched by the user threads scheduler. THis gets rid of all the masking and unmasking, and the associated protection domain crossing that happens currently in the user space threads library (in fact, you could do this in the current user space threads library by establishing a handler for all signals that's sole purpose was to reflect the signals into a user space signal dispatcher; this would make the user space threads significantly lighter weight, even without the KSE changes). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C8812C0.DE9060FB>