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
<[email protected]> 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.
