Date: Tue, 4 May 1999 16:16:13 -0700 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Peter Wemm <peter@netplex.com.au>, Luoqi Chen <luoqi@watermarkgroup.com> Cc: hackers@FreeBSD.ORG, peter.jeremy@auss2.alcatel.com.au Subject: Re: flock + kernel threads bug Message-ID: <199905042316.QAA06393@salsa.gv.tsc.tdk.com> In-Reply-To: Peter Wemm <peter@netplex.com.au> "Re: flock %2B kernel threads bug" (Apr 26, 8:29pm)
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905042316.QAA06393>