std.process - POSIX specific callback
nazriel
spam at dzfl.pl
Thu Jun 6 10:32:24 PDT 2013
On Thursday, 6 June 2013 at 17:18:20 UTC, Steven Schveighoffer
wrote:
> On Thu, 06 Jun 2013 12:05:14 -0400, nazriel <spam at dzfl.pl>
> wrote:
>
>> Would it be possible to add to std.process.Config POSIX
>> specific callback which would be called after fork()?
>>
>> It is currently main blocker in switching dpaste-be from
>> handmade process handling module to std.process.
>>
>> It could look something like this.
>>
>> struct Config {
>> // current fields
>> void delegate() posixCallback;
>> }
>>
>> // ...
>>
>> int i = fork();
>> if (i > 0)
>> {
>> //...
>> if (config.posixCallback !is null)
>> config.posixCallback();
>> //...
>> }
>>
>> Such construct would allow for various child process
>> manipulation, for instance
>> dropping root privileges or setting limits via setrmlimit.
>>
>> Example:
>>
>> config.posixCallback = {
>> setguid(ourGUID);
>> setgroups(ourGROUPS);
>> setuid(ourUID);
>>
>> setrmlimit(NFORK, 123);
>> };
>>
>>
>> AFAIK we already have Windows specific flag related to
>> spawning console for GUI apps.
>>
>> I can make pull request ASAP when I get reasonable name for
>> field.
>>
>> Lars? ;)
>
> I agree with the ability, but not with the interface. If this
> is to be done, it should be at a lower level, not inside
> config. Keep in mind that std.process is generalized for both
> Windows and Posix, with very minor differences.
>
> -Steve
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
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;
// ...
I would *really* love to see this implemented. It is really basic
stuff for posixen.
Thanks a lot for responding Steven.
More information about the Digitalmars-d
mailing list