Date: Thu, 01 Jul 1999 01:50:32 +0800 From: Peter Wemm <peter@netplex.com.au> To: Julian Elischer <julian@whistle.com> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern init_main.c kern_fork.c kern_linker.c vfs_aio.c src/sys/sys proc.h Message-ID: <19990630175032.2104479@overcee.netplex.com.au> In-Reply-To: Your message of "Wed, 30 Jun 1999 10:44:04 MST." <Pine.BSF.3.95.990630104113.12786A-100000@current1.whistle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote:
>
>
> On Wed, 30 Jun 1999, Garrett Wollman wrote:
>
> > <<On Wed, 30 Jun 1999 08:33:43 -0700 (PDT), Peter Wemm <peter@FreeBSD.org>
said:
> >
> > > syscalls set p->p_retval[] themselves. Simplify the SYSINIT_KT() code
> > > and other kernel thread creators to not need to use pfind() to find the
> > > child based on the pid. While here, partly tidy up some of the fork1()
> >
> > On an almost-unrelated tangent...
> >
> > Because proc structures are now stored in type-stable memory (via the
> > zone allocator), other places in the kernel which now reference
> > processes by pid and pfind should be able to keep a reference to the
> > proc instead. (There does need to be a version number which gets
> > incremented when proc structs are recycled, but this should still be
> > cheaper than pfind().) This would benefit network applications
> > written around a poll or select loop, since the simple case of
> > selwakeup() uses pfind() to locate the specific process to wake up.
>
> Bill Jolitz added the PID stuff because there can be races where
the proc structure is re-used..
> I can't remember the exact case but my gut feeling is that whatever it was
> is still there..
Oh yeah, there would have been good reason for it, since a proc pointer
could be pointing off to the void and get a page fault etc. But now,
struct proc is allocated from a zone, which only contains procs and pages
are never freed. Once a proc has been allocated, the pointer will always
point to a struct proc of some sort. We can then check to see if it's
still asleep in selwait directly without needing to search for the proc
pointer. If the old process has gone away, and a new one exists that also
happens to be asleep in select, it doesn't matter - it will run, scan the
bit vectors and go straight back to sleep. Crude, but that's select for
you.
> julian
Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990630175032.2104479>