Date: Mon, 07 Dec 1998 08:51:16 -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.19981207085116.00948a90@localhost> In-Reply-To: <199812071410.JAA17159@highwind.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 09:10 AM 12/7/98 -0500, HighWind Software Information wrote: >Second, I don't see why it is bad for a threaded program to call >fork(). Why not? Because you have no guarantee that all thread related resources have been properly freed using atfork() handlers. Since FreeBSD doesn't support atfork handlers, you'll actually likely to have lots of thread related resources dangling. Any one of these can bite you. Doing anything other than exec()/_exit() in the child, including close(), is likely to cause deadlock. If you want to write a portable pthread application, do not use fork() after using any pthread_*() calls. >What if you need to exec() sendmail or some other helper program? Do it immediately or use a surrogate parent! >Third, I still don't see why my patch is bad. After fork(), you have >one thread left. It makes no sense for the remaining fd's that are >open to be locked by threads that do not exist! Because I may want to use an atfork handler (once pthread_atfork() is implemented) to restart threads on the child. >If they are simply unlocked/cleaned up in the child, the child is then >free to close() or manipulate those fd's. 1) because it changes the process state of the child. 2) assumes that every application wants them unlocked. >This is the way it works on every other O/S. Becareful with absolutes. 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.19981207085116.00948a90>