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