From owner-freebsd-arch Wed Sep 19 21:23: 0 2001 Delivered-To: freebsd-arch@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id CA7F937B421; Wed, 19 Sep 2001 21:22:57 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id AAA23104; Thu, 20 Sep 2001 00:22:02 -0400 (EDT) Date: Thu, 20 Sep 2001 00:21:59 -0400 (EDT) From: Daniel Eischen To: John Baldwin , julian@FreeBSD.ORG, arch@FreeBSD.ORG Subject: Re: sigsuspend() and KSE In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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