threads/101323: fork(2) in threaded programs broken.

Poul-Henning Kamp phk at phk.freebsd.dk
Thu Aug 3 18:50:23 UTC 2006


The following reply was made to PR threads/101323; it has been noted by GNATS.

From: "Poul-Henning Kamp" <phk at phk.freebsd.dk>
To: Daniel Eischen <deischen at freebsd.org>
Cc: FreeBSD-gnats-submit at freebsd.org, freebsd-threads at freebsd.org
Subject: Re: threads/101323: fork(2) in threaded programs broken. 
Date: Thu, 03 Aug 2006 18:44:56 +0000

 In message <Pine.GSO.4.64.0608031417260.13543 at sea.ntplx.net>, Daniel Eischen wr
 ites:
 
 >No, that's not nearly enough.  This has been discussed in
 >-threads before.
 >
 >Forking from a multi-threaded program is just like an
 >asynchronous signal in an unthreaded program.  You have
 >no idea what state any of the libraries or application data
 >is in.
 
 ... Unless of course, the programmer too great care to make
 sure he did, and therefore assumes that fork() will actually
 be safe.
 
 In my case, I know the exact state of the entire process
 and I know 100% certain that there are no locks held which
 will affect the forked copy.
 
 ... except that holding all malloc's locks screws me over :-(
 
 I will agree that there is no "perfect" solution, but that is
 not what I'm after, I'm after "works in controlled circumstances.
 
 I would argue that an implementation that does:
 
 	hold any library locks we want to handle
 	fork
 	if (parent)
 		release those locks again
 		return
 	else
 		unlock all locks (since they cannot possibly
 		make sense in the child in a locked state)
 		return
 
 That would go a long way towards a "works if you're careful"
 implementation.
 
 -- 
 Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
 phk at FreeBSD.ORG         | TCP/IP since RFC 956
 FreeBSD committer       | BSD since 4.3-tahoe    
 Never attribute to malice what can adequately be explained by incompetence.


More information about the freebsd-threads mailing list