On Mon, 10 Jun 2013 16:05:15 -0400, Lars T. Kyllingstad
<[email protected]> wrote:
On Monday, 10 June 2013 at 16:20:53 UTC, Steven Schveighoffer wrote:
But I think we need some way to hook this. To give up all the niceties
of std.process just so you can hook the fork/exec sequence seems overly
burdensome.
But with the pthread_atfork() solution you don't have to. Call that
function before you call spawnProcess() or any of the other std.process
functions, and it should Just Work (TM). The nice thing here is that it
is already part of the POSIX standard, and thus should be available on
all relevant systems, and we don't have to adapt our cross-platform API
at all.
This is not a good solution. It deals with the idea that when forking,
only the calling thread is alive, all other threads are dead, and one of
those dead threads may hold a lock. Also note that the function pointers
are function pointers, not delegates.
The idea is that prior to fork, you lock all mutexes you want to be
unlocked. Then after fork is called, you unlock those mutexes (thus
ensuring no dead threads hold the locks).
I don't think it makes for a very good generalized solution to "I want to
run this arbitrary code".
Also, according to SO, it doesn't even do what it means to do, since the
newly created process thread can't unlock the mutexes:
http://stackoverflow.com/questions/2620313/how-to-use-pthread-atfork-and-pthread-once-to-reinitialize-mutexes-in-child
Not only that, but it seems to be permanent -- there is no "unregister
pthread_atfork" call. So this has to be a one-time *process-wide* and
permanent solution. If you wanted to run code for this specific call to
spawnProcess, and not others, then you are SOL.
And finally, if your ultimate purpose is to call exec right after fork (as
it is in the general case), you are penalized by having to wait for some
mutex to be unlocked in order to fork.
-Steve
