Date: Mon, 26 Apr 1999 08:09:16 -0400 (EDT) From: Luoqi Chen <luoqi@watermarkgroup.com> To: peter@netplex.com.au Cc: hackers@FreeBSD.ORG, peter.jeremy@auss2.alcatel.com.au Subject: Re: flock + kernel threads bug Message-ID: <199904261209.IAA13139@lor.watermarkgroup.com>
next in thread | raw e-mail | index | archive | help
> 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(). > Cheers, > -Peter > -lq 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?199904261209.IAA13139>