Date: Fri, 5 Mar 1999 08:06:18 -0800 From: John Plevyak <jplevyak@inktomi.com> To: Terry Lambert <tlambert@primenet.com>, John Plevyak <jplevyak@inktomi.com> Cc: hackers@FreeBSD.ORG Subject: Re: lockf and kernel threads Message-ID: <19990305080618.B22589@tsdev.inktomi.com> In-Reply-To: <199903050354.UAA25677@usr01.primenet.com>; from Terry Lambert on Fri, Mar 05, 1999 at 03:54:13AM %2B0000 References: <19990303120101.A21432@proxydev.inktomi.com> <199903050354.UAA25677@usr01.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990305080618.B22589>