On Tue, 11 Jun 2013 12:31:19 -0400, Lars T. Kyllingstad
<[email protected]> 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
