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