From owner-freebsd-hackers  Mon Apr 26  5: 9:55 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33])
	by hub.freebsd.org (Postfix) with ESMTP id 606F61515F
	for <hackers@FreeBSD.ORG>; Mon, 26 Apr 1999 05:09:17 -0700 (PDT)
	(envelope-from luoqi@watermarkgroup.com)
Received: (from luoqi@localhost)
	by lor.watermarkgroup.com (8.8.8/8.8.8) id IAA13139;
	Mon, 26 Apr 1999 08:09:16 -0400 (EDT)
	(envelope-from luoqi)
Date: Mon, 26 Apr 1999 08:09:16 -0400 (EDT)
From: Luoqi Chen <luoqi@watermarkgroup.com>
Message-Id: <199904261209.IAA13139@lor.watermarkgroup.com>
To: peter@netplex.com.au
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

> 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