From owner-freebsd-current Thu Dec 3 12:40:39 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA19017 for freebsd-current-outgoing; Thu, 3 Dec 1998 12:40:39 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from galois.boolean.net (galois.boolean.net [209.133.111.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA19012 for ; Thu, 3 Dec 1998 12:40:38 -0800 (PST) (envelope-from Kurt@OpenLDAP.Org) Received: from gypsy (galois.boolean.net [209.133.111.74]) by galois.boolean.net (8.8.8/8.8.8) with SMTP id UAA12342; Thu, 3 Dec 1998 20:53:18 GMT (envelope-from Kurt@OpenLDAP.Org) Message-Id: <3.0.5.32.19981203124540.00b03b80@localhost> X-Sender: guru@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Dec 1998 12:45:40 -0800 To: HighWind Software Information From: "Kurt D. Zeilenga" Subject: Re: Thread fd locking and fork() Cc: current@FreeBSD.ORG In-Reply-To: <199812031735.MAA01016@highwind.com> References: <199812031522.KAA28193@highwind.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 12:35 PM 12/3/98 -0500, HighWind Software Information (rob) wrote: >Is there any solution to this? I would recommend using a surrogate parent model described by Nichols, "Pthreads Programming", p190. Basically, fork a child as soon as possible (before any pthread_* call). This child process can than act as a surrograte. When the parent wants to fork()/exec(), it communicates this to the surrogate using any number of IPC mechanisms. >Perhaps the fork() code should unlock all the descriptors. Be very careful changing the semantics of fork()... In a Posix Threads environment, state of locks should not be changed. If it's locked in the parent it must be locked in the child. Posix Threads provides the pthread_atfork() function to allow the parent to specify routines to manage fork()'ing... however it's not implemented in FreeBSD. If it was, you could argue that -lc_r probably should push an atfork cleanup handler. Having fork() itself to the cleanup, IMHO, is not wise. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message