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

[Poul-Henning Kamp]

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.