From owner-freebsd-current  Fri Dec  4 14:08:34 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id OAA27397
          for freebsd-current-outgoing; Fri, 4 Dec 1998 14:08:34 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from highwind.com (hurricane.highwind.com [209.61.45.50])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA27392
          for <current@FreeBSD.ORG>; Fri, 4 Dec 1998 14:08:32 -0800 (PST)
          (envelope-from info@highwind.com)
Received: (from info@localhost)
	by highwind.com (8.8.6/8.8.6) id RAA12304;
	Fri, 4 Dec 1998 17:07:58 -0500 (EST)
Date: Fri, 4 Dec 1998 17:07:58 -0500 (EST)
Message-Id: <199812042207.RAA12304@highwind.com>
From: HighWind Software Information <info@highwind.com>
To: tlambert@primenet.com
CC: current@FreeBSD.ORG
In-reply-to: <199812042133.OAA06102@usr01.primenet.com> (message from Terry
	Lambert on Fri, 4 Dec 1998 21:33:45 +0000 (GMT))
Subject: Re: Thread fd locking and fork()
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


>   Then don't explicitly call close after the exec, since the fork()
>   wrapper in libc_r will Do The Right Thing(tm).

What is the problem with calling close() after the exec()? That is a
100% valid thing to do.

Saying, "do this instead" is nice, but doesn't address the bug in
libc_r.

Also, if you call fcntl() after the fork(), you will hang. The only
thing you can do is fcntl() all your descriptors before the fork().

That is a bit crazy because you have to juggle everytime you want to
do a fork()/exec(). Calling fcntl() in the parent also introduces
other race conditions as other parts of the system might be calling
fork().

My patch seems to fix it.

-Rob


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message