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