std.process - POSIX specific callback
Steven Schveighoffer
schveiguy at yahoo.com
Mon Jun 10 13:26:56 PDT 2013
On Mon, 10 Jun 2013 16:05:15 -0400, Lars T. Kyllingstad
<public at kyllingen.net> 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
More information about the Digitalmars-d
mailing list