Date: Thu, 20 Sep 2001 00:21:59 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: John Baldwin <jhb@FreeBSD.ORG>, julian@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: sigsuspend() and KSE Message-ID: <Pine.SUN.3.91.1010920000641.21385A-100000@pcnet1.pcnet.com> In-Reply-To: <Pine.SUN.3.91.1010919195624.17296A@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Sep 2001, Daniel Eischen wrote: > On Wed, 19 Sep 2001, John Baldwin wrote: > > >From the KSE commit the following was added regarding sigsuspend: > > > > /* > > * Suspend process until signal, providing mask to be set > > * in the meantime. Note nonstandard calling convention: > > * libc stub passes mask, not pointer, to save a copyin. > > ***** XXXKSE this doesn't make sense under KSE. > > ***** Do we suspend the thread or all threads in the process? > > ***** How do we suspend threads running NOW on another processor? > > */ > > > > Here's my opinion: > > > > sigsuspend() just suspends the current thread. When a signal is posted, it > > wakes up all threads blocked on sigsuspend whose mask matches that signal. I > > can see it still making sense, but perhaps being of limited usefulness in a > > threaded program. > > Right. sigsuspend should only block the calling thread and result > into an upcall into the threads library. This really shouldn't > be any different than a thread blocking on I/O. Since signals [...] Thinking about this a bit more, the threads library already wraps sigsuspend(). I think it might have to for a KSE-based threads library also. The UTS needs to know what the suspended signal mask is in order to properly determine which thread a signal should be sent to. The kernel could pass the suspended signal mask up to the UTS when the calling thread sigsuspends, but this seems a bit too special case for something that is easily (and is already) wrapped by the threads library. So if you wanted to ignore the case of sigsuspend in a multi- threaded process, I don't think it'll be a problem. We do need a way for the KSE to tell the kernel "Hey, I have no more work to do, but may have at some point in the future". If you made sigsuspend/signanosleep on a per-KSE basis, the KSE could use these system calls to do exactly that. You would still need a separate system call to wake them though since kill() operates on the process. -- Dan Eischen 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?Pine.SUN.3.91.1010920000641.21385A-100000>