I am trying to create a program that handles two types of processes:
* Scripts and executables that it runs directly
* Daemons that fork and exit, with a pid file containing the pid of the lingering daemon process
I want to handle them in the same fashion. It would be convenient to use std.process to do so.
I can easily parse an integer from a pid file, but in order to construct a std.process.Pid from that, I need to resort to tupleof hacks and manually constructing class instances.
It would be better if std.process.Pid exposed its constructors publicly.
For now, I'm using core.sys.posix directly. If I wanted to support Windows, though, I'd have to copy std.process into my project and make the relevant constructors public to handle things in a reasonable fashion.
Comment #1 by dlang-bugzilla — 2017-06-08T12:29:00Z
(In reply to Chris Wright from comment #0)
> I want to handle them in the same fashion.
Why? Waiting on a process that is not your child is not possible, so in that way, this would allow constructing an invalid Pid. Is it just for .kill()?
Comment #2 by dlang-bugzilla — 2017-06-08T12:29:38Z
You can wait for a process that you called ptrace for:
PTRACE_O_TRACEEXIT (since Linux 2.5.60)
Stop the tracee at exit. A waitpid(2) by the tracer will return a status value such that...
On the other hand, it might be simpler to just use pids for everything.
Comment #4 by dlang-bugzilla — 2017-06-11T21:46:41Z