From owner-freebsd-hackers Tue Apr 20 23:13:13 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 9BB5714F54 for ; Tue, 20 Apr 1999 23:13:11 -0700 (PDT) (envelope-from jplevyak@inktomi.com) Received: from tsdev (tsdev.inktomi.com [209.1.32.119]) by mercury.inktomi.com (8.9.1a/8.9.1) with ESMTP id XAA06333; Tue, 20 Apr 1999 23:10:50 -0700 (PDT) Received: (from jplevyak@localhost) by tsdev (SMI-8.6/) id XAA28515; Tue, 20 Apr 1999 23:10:43 -0700 Message-ID: <19990420231043.A27095@tsdev.inktomi.com> Date: Tue, 20 Apr 1999 23:10:43 -0700 From: John Plevyak To: Luoqi Chen , dick@tar.com, jplevyak@inktomi.com Cc: hackers@FreeBSD.ORG Subject: Re: flock + kernel threads bug References: <199904210224.WAA20594@lor.watermarkgroup.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <199904210224.WAA20594@lor.watermarkgroup.com>; from Luoqi Chen on Tue, Apr 20, 1999 at 10:24:50PM -0400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, Apr 20, 1999 at 10:24:50PM -0400, Luoqi Chen wrote: > > This is a different (bigger) problem, i.e. pid sharing among threads, > it is also desirable for signal handling. I doubt that which id is stored in > the lock really matters, and this issue will go away as soon as we solve > the bigger pid sharing problem. > > For the current problem at hand, we want a solution that works for both > threads and non-threads. > I see what you mean: since the PIDs would be stored in the table it matters little what they are so long as they are unique. The patch does prevent conflicts with recycled PIDs for what it is worth. So, there are 2 solutions for this problem, but they are not in conflict as they are really general solutions in different domains, and I can envision both eventually being used for different reasons. Given that, I guess I am proposing the idea of using of storing process specific information in p->p_leader and preventing the leader from terminating as a step in moving toward more standard kernel thread semantics. I am also motivated since it fixes a bug which I find particularly onerous. Regarding storing the PIDs with the fds: I like the idea, but I understand that NFS locking also has issues and I am wondering how if those might be addressed as well by a locking solution. john -- John Bradley Plevyak, PhD, jplevyak@inktomi.com, PGP KeyID: 051130BD Inktomi Corporation, 1900 S. Norfolk Street, Suite 310, San Mateo, CA 94403 W:(650)653-2830 F:(650)653-2889 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