std.process - POSIX specific callback

[Steven Schveighoffer]

On Fri, 07 Jun 2013 01:59:22 -0400, Lars T. Kyllingstad
<public at kyllingen.net> wrote:

> On Thursday, 6 June 2013 at 17:32:25 UTC, nazriel wrote:
>> I am aware that std.process is generalized but I doubt such useful  
>> functionality which is usable on various Posixen is more disturbing  
>> than Windows-only suprpressConsole  
>> https://github.com/D-Programming-Language/phobos/blob/master/std/process.d#L954
>
> I think there is a huge difference between a simple flag and the
> ability to execute arbitrary code on one OS but not on another.
> (When set, suppressConsole actually *eliminates* a difference in
> the default behaviour of the two OS families.)

First, suppressConsole is a simple flag, basically passed through to the
CreateProcess function, so even though it's Windows-specific, so is the
behavior we are suppressing.  Consider that when you specify
suppressConsole on Posix, the flag works!  No console window is created :)

But what to do with arbitrary "run this code between fork and exec" on
windows?  It's not possible.  It doesn't belong in the generalized API.

>> But I was mistaken. Config is an enum not struct, so yeah, not worth  
>> changing it only for sake of posix callback.
>>
>> So maybe module level variable?
>>
>> module std.process;
>>
>> // ...
>> void delegate() posixPostFork = null;
>> // ...
>
> Global state?  Don't want to go there...

I agree that the global state is a bad idea, ideally you want to specify
PER CALL what happens on a fork/exec, not PER THREAD (or PER PROCESS).

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.

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).

Does this make sense?  I think it can be done without breaking any code.   
May be a lot of boilerplate :)

-Steve