std.process - POSIX specific callback

Steven Schveighoffer schveiguy at yahoo.com
Tue Jun 11 10:18:58 PDT 2013


On Tue, 11 Jun 2013 12:31:19 -0400, Lars T. Kyllingstad  
<public at kyllingen.net> wrote:

> On Monday, 10 June 2013 at 16:20:53 UTC, Steven Schveighoffer wrote:
>> What I am thinking of is possibly to expose the OS-specific  
>> spawnProcess implementation as an object with the API defined by it,  
>> similar to how writeln simply forwards to stdout.writeln.  We could  
>> have spawnProcess simply forward to posixProcessImpl.spawnProcess (or  
>> windowsProcessImpl.spawnProcess on windows)
>>
>> Then if someone wants to actually take advantage of OS-specific  
>> features, they can call on the appropriate object.  It shouldn't  
>> compile where it's not implemented (e.g. windows spawnProcess shouldn't  
>> be callable on Linux).
>
> Why should we add an object?  Why not expose the OS-specific  
> spawnProcess() implementation as it is -- a free function -- with an  
> additional parameter which specifies a callback delegate?

We could do that too.  The only thing is that the implementation function  
is more rough -- it doesn't have all the nice overloads.  I was thinking  
of simply moving the overloads to an object, and then calling on the  
object's overloads.

But thinking about it now, it doesn't make sense.  The object's overloads  
would all have to support this callback parameter.  It's probably best to  
simply expose the underlying implementation.

The documentation should explicitly warn about this...  From reading the  
pthread_atfork man page, it is clear that there are very significant  
problems that can arise from running arbitrary code at that time.

> Can you think of any other places we'd want to hook besides  
> post-fork-pre-exec?

I can't think of anything else at the moment.  If we ever support async  
events in Phobos, we should add an event for "child exited".

-Steve


More information about the Digitalmars-d mailing list