From owner-freebsd-hackers Wed Aug 19 17:19:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA06765 for freebsd-hackers-outgoing; Wed, 19 Aug 1998 17:19:04 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from cimlogic.com.au (cimlog.lnk.telstra.net [139.130.51.31]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA06741 for ; Wed, 19 Aug 1998 17:19:00 -0700 (PDT) (envelope-from jb@cimlogic.com.au) Received: (from jb@localhost) by cimlogic.com.au (8.8.8/8.8.7) id KAA03965; Thu, 20 Aug 1998 10:27:47 +1000 (EST) (envelope-from jb) From: John Birrell Message-Id: <199808200027.KAA03965@cimlogic.com.au> Subject: Re: sfork()? In-Reply-To: <199808191637.QAA03513@dingo.cdrom.com> from Mike Smith at "Aug 19, 98 04:37:57 pm" To: mike@smith.net.au (Mike Smith) Date: Thu, 20 Aug 1998 10:27:47 +1000 (EST) Cc: hackers@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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