Date: Thu, 03 Dec 1998 12:45:40 -0800 From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.Org> To: HighWind Software Information <info@highwind.com> Cc: current@FreeBSD.ORG Subject: Re: Thread fd locking and fork() Message-ID: <3.0.5.32.19981203124540.00b03b80@localhost> In-Reply-To: <199812031735.MAA01016@highwind.com> References: <199812031522.KAA28193@highwind.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3.0.5.32.19981203124540.00b03b80>