From owner-freebsd-hackers Fri Mar 5 8: 6:38 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mercury.inktomi.com (mercury.inktomi.com [209.1.32.126]) by hub.freebsd.org (Postfix) with ESMTP id 8FF0515039 for ; Fri, 5 Mar 1999 08:06:36 -0800 (PST) (envelope-from jplevyak@inktomi.com) Received: from tsdev.inktomi.com (tsdev.inktomi.com [209.1.32.119]) by mercury.inktomi.com (8.9.1a/8.9.1) with SMTP id IAA15404; Fri, 5 Mar 1999 08:06:28 -0800 (PST) Received: by tsdev.inktomi.com (SMI-8.6/SMI-SVR4) id IAA22611; Fri, 5 Mar 1999 08:06:18 -0800 Message-ID: <19990305080618.B22589@tsdev.inktomi.com> Date: Fri, 5 Mar 1999 08:06:18 -0800 From: John Plevyak To: Terry Lambert , John Plevyak Cc: hackers@FreeBSD.ORG Subject: Re: lockf and kernel threads References: <19990303120101.A21432@proxydev.inktomi.com> <199903050354.UAA25677@usr01.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199903050354.UAA25677@usr01.primenet.com>; from Terry Lambert on Fri, Mar 05, 1999 at 03:54:13AM +0000 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, Mar 05, 1999 at 03:54:13AM +0000, Terry Lambert wrote: > > > I think you can do this by recursing on the peers in the middle > > > of handling the kill before you pass it to the trampoline (then > > > it's too late). > > > > Why is it too late after that? In the patch I did the wait in exit1() > > right after the 'kill' of the peers. > > It's too late if you've gone to user space with the signal, because > it's an untrappable signal. That's the trampoline I was referring > to. I understand about the trampoline, but I don't see why you can't send the signal out of user space, mostly because that is what 3.0+ currently does! (near the beginning of exit1() to all peers of a p_leader.) > Right. Such a structure is essentially identical in content to > an async call context for an async call gate, BTW. 8-). I am missing context on this, however if it was a mechanism for generalized async calls w/o signals/polling but 'wait for one of N events' I am interested. > I actually think that relying on the unlock as a side effect of > the close is probably bad form. But I understand how it could > come abut from a strict reading of POSIX. The close is really an implementation detail, since it is the mechanism by which the kernel releases the lock when the process exits. I could live with the lock persisting beyond the close (just more bookkeeping on my part), but not with it persisting beyond the exit of the processes (since I cannot trap 'kill -9'). > You might be able to get someone to commit this, at least as a short > term soloution to the problem. It would get you over the "blessed" > hump so you can concentrate on more pressing issues. Hummm... any guesses as to whom might be most sympathetic? john > > > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. -- John Bradley Plevyak, PhD, jplevyak@inktomi.com, PGP KeyID: 051130BD Inktomi Corporation, 1900 S. Norfolk Street, Suite 110, San Mateo, CA 94403 W:(415)653-2830 F:(415)653-2801 P:(888)491-1332/5103192436.4911332@pagenet.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message