Date: Mon, 26 Apr 1999 20:29:31 +0800 From: Peter Wemm <peter@netplex.com.au> To: Luoqi Chen <luoqi@watermarkgroup.com> Cc: hackers@FreeBSD.ORG, peter.jeremy@auss2.alcatel.com.au Subject: Re: flock + kernel threads bug Message-ID: <19990426122933.063D91F58@spinner.netplex.com.au> In-Reply-To: Your message of "Mon, 26 Apr 1999 08:09:16 -0400." <199904261209.IAA13139@lor.watermarkgroup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990426122933.063D91F58>