From owner-freebsd-hackers Mon Apr 26 5:29:45 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from spinner.netplex.com.au (spinner.netplex.com.au [202.12.86.3]) by hub.freebsd.org (Postfix) with ESMTP id F2DAD14C21 for ; Mon, 26 Apr 1999 05:29:34 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by spinner.netplex.com.au (Postfix) with ESMTP id 063D91F58; Mon, 26 Apr 1999 20:29:31 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Luoqi Chen Cc: hackers@FreeBSD.ORG, peter.jeremy@auss2.alcatel.com.au Subject: Re: flock + kernel threads bug In-reply-to: Your message of "Mon, 26 Apr 1999 08:09:16 -0400." <199904261209.IAA13139@lor.watermarkgroup.com> Date: Mon, 26 Apr 1999 20:29:31 +0800 From: Peter Wemm Message-Id: <19990426122933.063D91F58@spinner.netplex.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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(). 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.. FWIW, a 32-bit secondary pid is probably a good (or better) generation number for this sort of thing (and elsewhere, as long as it's not exposed to users). Hmm, perhaps... Hmmmmm.. Perhaps create a 32 bit "thread id" now and use that for process/identification in things like this. At some point down the track, pid's can become non-unique when there is a proc/thread split. > -lq Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message