Date: Wed, 30 Jun 1999 11:04:42 -0700 (PDT) From: Julian Elischer <julian@whistle.com> To: "Brian F. Feldman" <green@unixhelp.org> Cc: Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Peter Wemm <peter@FreeBSD.org>, 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: <Pine.BSF.3.95.990630105951.12786D-100000@current1.whistle.com> In-Reply-To: <Pine.BSF.4.10.9906301357250.50480-100000@janus.syracuse.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > > > > > <<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.. > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990630105951.12786D-100000>