Date: Wed, 19 Aug 1998 12:25:23 -0500 (EST) From: Alfred Perlstein <bright@www.hotjobs.com> To: "Ron G. Minnich" <rminnich@sarnoff.com> Cc: hackers@FreeBSD.ORG Subject: Re: sfork()? Message-ID: <Pine.BSF.3.96.980819121409.19467A-100000@bright.fx.genx.net> In-Reply-To: <Pine.SUN.3.91.980819115941.12330A-100000@terra>
next in thread | previous in thread | raw e-mail | index | archive | help
yes, evil evil evil man pages. :) and, actually John Dyson told me about rfork, i thought it was "fixed" though. the argument that rfork shouldn't copy the stack is bogus, as fork does it, and copying the stack in userland sounds silly. (wrapping a call to rfork) what are the implications of doing certain things after the cludged split? what i mean will exit() and other stuff be munged? the wrapper John gave me is interesting (still trying to get it to work, as i'm confused about the arguments) but i _think_ you can't return from your "thread" because the stack just isn't there. are people still working on kernel threads instead of userland threads? Alfred Perlstein - Programmer, HotJobs Inc. - www.hotjobs.com -- There are operating systems, and then there's BSD. -- http://www.freebsd.org/ On Wed, 19 Aug 1998, Ron G. Minnich wrote: > On Wed, 19 Aug 1998, Jonathan Lemon wrote: > > You apparently also need some assembly code to handle management > > of the stack; from my understanding, both processes will share > > the same stack on return from rfork(), and stomp on each other. > > from the man page: > > RFMEM ... The stack segment is always split. May be set only with > RFPROC. > > so the stack is not shared from my reading. My rfork() for 2.0.x split > the stack to. > > ron > 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.3.96.980819121409.19467A-100000>