Date: Thu, 03 Aug 2006 18:44:56 +0000 From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: Daniel Eischen <deischen@freebsd.org> Cc: FreeBSD-gnats-submit@freebsd.org, freebsd-threads@freebsd.org Subject: Re: threads/101323: fork(2) in threaded programs broken. Message-ID: <49575.1154630696@critter.freebsd.dk> In-Reply-To: Your message of "Thu, 03 Aug 2006 14:34:04 -0400." <Pine.GSO.4.64.0608031417260.13543@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.GSO.4.64.0608031417260.13543@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49575.1154630696>