From owner-freebsd-smp Fri Sep 8 16:32:34 2000 Delivered-To: freebsd-smp@freebsd.org Received: from io.yi.org (24.67.218.186.bc.wave.home.com [24.67.218.186]) by hub.freebsd.org (Postfix) with ESMTP id B3F5537B443 for ; Fri, 8 Sep 2000 16:32:31 -0700 (PDT) Received: from io.yi.org (localhost.gvcl1.bc.wave.home.com [127.0.0.1]) by io.yi.org (Postfix) with ESMTP id D27EBBA6D; Fri, 8 Sep 2000 16:33:01 -0700 (PDT) X-Mailer: exmh version 2.1.1 10/15/1999 To: Daniel Eischen Cc: Alfred Perlstein , smp@FreeBSD.ORG Subject: Re: SMPng: catching signals and mutexes. In-Reply-To: Message from Daniel Eischen of "Fri, 08 Sep 2000 15:48:18 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Sep 2000 16:33:01 -0700 From: Jake Burkholder Message-Id: <20000908233301.D27EBBA6D@io.yi.org> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Fri, 8 Sep 2000, Alfred Perlstein wrote: > > There seems to be no way to specify that a signal is to interrupt > > a wait on a mutex, I'm wondering if we should make it possible to > > do so. > > [...] > > > I'm not sure I like this at all, shouldn't there be an > > mtx_enter with some option to return an error if a signal > > arrives? > > IMHO, yes. Solaris has cv_wait_sig() for just that. > Mutexes are meant to serve a different purpose than tsleep or condition variables. The next thing in line is to add a mutex argument to tsleep, which will be atomicly released and re-acquired upon resume. The code in question might then look like: mtx_enter(&sb->sb_mtx, MTX_DEF); while (sb->sb_flags & SB_LOCK) { sb->sb_flags |= SB_WANT; error = tsleep((caddr_t)&sb->sb_flags, sb->sb_mtx, (sb->sb_flags & SB_NOINTR) ? PSOCK : PSOCK|PCATCH, "sblock", 0); if (error) { mtx_exit(sb->sb_mtx, MTX_DEF); return (error); } } sb->sb_flags |= SB_LOCK; mtx_exit(sb->sb_mtx, MTX_DEF); Jake To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message