From owner-freebsd-current Mon Dec 7 08:46:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA17139 for freebsd-current-outgoing; Mon, 7 Dec 1998 08:46:31 -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 IAA17130 for ; Mon, 7 Dec 1998 08:46:25 -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 RAA24574; Mon, 7 Dec 1998 17:00:15 GMT (envelope-from Kurt@OpenLDAP.Org) Message-Id: <3.0.5.32.19981207085116.00948a90@localhost> X-Sender: guru@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 07 Dec 1998 08:51:16 -0800 To: HighWind Software Information From: "Kurt D. Zeilenga" Subject: Re: Thread fd locking and fork() Cc: current@FreeBSD.ORG In-Reply-To: <199812071410.JAA17159@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 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