From owner-cvs-all Wed Jun 30 10:51:22 1999 Delivered-To: cvs-all@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 16B6A15789; Wed, 30 Jun 1999 10:50:33 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id 2104479; Thu, 1 Jul 1999 01:50:32 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.0.2 2/24/98 To: Julian Elischer Cc: Garrett Wollman , 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 In-reply-to: Your message of "Wed, 30 Jun 1999 10:44:04 MST." Date: Thu, 01 Jul 1999 01:50:32 +0800 From: Peter Wemm Message-Id: <19990630175032.2104479@overcee.netplex.com.au> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk Julian Elischer wrote: > > > On Wed, 30 Jun 1999, Garrett Wollman wrote: > > > < 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