From owner-cvs-all Wed Jun 30 11: 4:49 1999 Delivered-To: cvs-all@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 16659155AB; Wed, 30 Jun 1999 11:04:45 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id LAA33558; Wed, 30 Jun 1999 11:04:42 -0700 (PDT) Date: Wed, 30 Jun 1999 11:04:42 -0700 (PDT) From: Julian Elischer To: "Brian F. Feldman" Cc: Garrett Wollman , Peter Wemm , 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: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Wed, 30 Jun 1999, Brian F. Feldman wrote: > On Wed, 30 Jun 1999, 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.. > > I thought about this a LOT, and it's not a great idea to hold a pointer to > the proc... I understand how "type stable storage" alters the situation, but I worry about the following cases. 1/ at some point in the future a different allocation scheme is used. 2/ at some point in the future teh zone allocator is taught to reclaim totally unused pages of zone memory. (I've seen such system) these may not be valid concerns, but worth a quick though.. Also, all cases that presently look up the proc structure from a stored pid need to now store a proc * and a sequence number. certainly doable.. but semantically different. What do you do in the case where it doesn't match? julian > > > > > julian > > > > > > > > > > > > -GAWollman > > > > > > -- > > > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same > > > wollman@lcs.mit.edu | O Siem / The fires of freedom > > > Opinions not those of| Dance in the burning flame > > > MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick > > > > > > > > > > > > > > Brian Fundakowski Feldman _ __ ___ ____ ___ ___ ___ > green@FreeBSD.org _ __ ___ | _ ) __| \ > FreeBSD: The Power to Serve! _ __ | _ \._ \ |) | > http://www.FreeBSD.org/ _ |___/___/___/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message