From owner-freebsd-hackers Tue May 4 16:16:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 1EC4214E65 for ; Tue, 4 May 1999 16:16:43 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id QAA05762; Tue, 4 May 1999 16:16:22 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id QAA18280; Tue, 4 May 1999 16:16:21 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA06393; Tue, 4 May 1999 16:16:13 -0700 (PDT) From: Don Lewis Message-Id: <199905042316.QAA06393@salsa.gv.tsc.tdk.com> Date: Tue, 4 May 1999 16:16:13 -0700 In-Reply-To: Peter Wemm "Re: flock + kernel threads bug" (Apr 26, 8:29pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Peter Wemm , Luoqi Chen Subject: Re: flock + kernel threads bug Cc: hackers@FreeBSD.ORG, peter.jeremy@auss2.alcatel.com.au Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Apr 26, 8:29pm, Peter Wemm wrote: } Subject: Re: flock + kernel threads bug } Luoqi Chen wrote: } > > Luoqi Chen wrote: } > > } > > > I've been thinking about a more drastic one, store the same PID in the } > > > threads' proc structure. PID is no more than a name of a process in the } > > > userland, and in userland we see all the threads as the same process. } > > > I don't think we really need a thread id, the threads are anonymous. } > > > Inside the kernel, the threads or processes are still named by their } > > > (struct proc *) pointer, so there won't be any confusion. } > > } > > selwakeup() is keyed from pid, not 'struct proc *' and is rather dependent } > > on these being unique... } > > } > I could see why pid is used here, the process selecting on the fd may have } > disappeared. Using pid doesn't solve the problem completely, another process } > may have assumed the same pid. A better solution would be store both struct } > proc * and pid, and use pid as some kind of generation number: if this pid } > is different from p_pid in struct proc, we know the original struct proc * } > must have gone (with the rare exception that another process has assumed } > both the struct proc storage and pid number). We could do this because } > struct proc's are allocated from type safe storage. This would save us the } > costly pfind(). I solved a similar problem with F_SETOWN and friends. See kern/7899 for more details, though the final patch is slightly different. } In order to minimize select very costly select wakeup collisions, we need } to be able to track multiple waiters.. Tracking a couple of hundred } waiters on a selinfo multiplies any extra storage.. Yeah, the solution I used for F_SETOWN, might be too heavy-weight for select(). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message