std.process - POSIX specific callback

nazriel spam at dzfl.pl
Tue Jun 11 12:06:46 PDT 2013


On Monday, 10 June 2013 at 16:20:53 UTC, Steven Schveighoffer 
wrote:
> 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)
>

I had no time yet to check out the pthread_atfork approach but I 
see you found some issue with that.

posixProcessImpl.spawnProcess and windowsProcessImpl.spawnProcess 
sounds very good.

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

That would be great.
Being able to use the easy, simple functions to get the work done 
and encourage to use them (by Docs and examples) but also allow 
access to more specialized, "less visible" functions as you 
proposed.

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

Thank you very much for looking into this.


More information about the Digitalmars-d mailing list