Date: Thu, 20 Aug 1998 10:27:47 +1000 (EST) From: John Birrell <jb@cimlogic.com.au> To: mike@smith.net.au (Mike Smith) Cc: hackers@FreeBSD.ORG Subject: Re: sfork()? Message-ID: <199808200027.KAA03965@cimlogic.com.au> In-Reply-To: <199808191637.QAA03513@dingo.cdrom.com> from Mike Smith at "Aug 19, 98 04:37:57 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Smith wrote: > Talk to John Dyson and perhaps check the archives to see why our > rfork() behaves like this. If it turns out that our rfork() is wrong, > or bad, or nonstandard, then please submit some diffs to fix it. > > Unless there are compelling (eg. thread-related) reasons, I don't see > why we shouldn't try to make it useful to its ultimate consumers. Remember that a thread implementation has to be able to allocate a user-specified amount of stack and that this is specified in the thread attributes. The rfork() call doesn't provide enough information for the kernel to create a thread with these attributes. This indicates that a separate syscall is required. Well, there is one already there, but that doesn't have the required semantics and isn't built into libc anyway. It should be cleaned up before 3.0 is shipped, IMHO. The handling of kernel threads in the pid model of the kernel needs work. Try getting one thread to exit, leaving the other threads running and you'll understand what I mean. I have all the code to handle this - I just put it aside while there were VM instabilities that had an impact on the validity of the ldt that was set to keep the pointer to the running thread. -- John Birrell - jb@cimlogic.com.au; jb@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 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?199808200027.KAA03965>