Date: Tue, 11 Jan 2000 11:31:28 -0500 (EST) From: Michael Bacarella <mbac@nyct.net> To: "Ronald G. Minnich" <rminnich@lanl.gov> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: rfork() [was: Concept check] Message-ID: <Pine.BSF.4.05.10001111117380.10711-100000@bsd1.nyct.net> In-Reply-To: <Pine.LNX.4.20.0001110911320.1512-100000@mini.acl.lanl.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Almost all of the flags it accepts seem like functionality that can easily > > be implemented in userspace around fork() (and maybe vfork()). > > nope. This whole issue is about (let me check :-) ) 4.5 years old. I did > the first rfork for freebsd ca. 9/1994, and I can tell you that you can't > easily get what it does with userland wrappers. Well, actually, in the > general case it's impossible. Just think about that fact that with shared > file descriptors, a child can open a socket and the parent can use it, > right down to using the same FD #. (And yes, I use this). I don't want to > try to emulate that behaviour in userland. > Fork and vfork, however, are a subset of rfork. Oh.... Yes, that perspective is much more different and sensible. One such as me might say that it makes more sense to turn fork() and vfork() into userland wrappers for rfork()! Too bad rfork is an afterthought, and then there are those people that want their fork()s without userland overhead. Pfft. :) -MB To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" 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.4.05.10001111117380.10711-100000>