We found procxx project several years ago and used it from time to time. In the last usage, I found two important issues:
usage of procxx leads to the termination of the parent process if a child process exits early and closes its input stream. In that case a call to pipe_t::write in the parent throws, then the flush() method is called from a destructor and that flush() throws another time. But because the second throw is performed during stack unwinding that throw leads to std::terminate;
inability to do some cleanup and preparation actions before the call to execvp() in a child process.
To resolve those issues I've made a refactoring of procxx implementation. Now there are methods that accept special nothrow value and do not throw on error. Instances of std::error_code are returned instead (or std::pair<std::error_code,std::size_t>). Those non-throwing methods are used for cleanup procedures (in destructors, for example).
There is also a variant of process::exec() method that accepts a callback. This callback is called in child/parent processes just after the return from fork().
The current version of my updated procxx fork can be found here (the revisited branch).
I can make a PR, but I think it has a sense only if that PR will be accepted. But because of procxx looks like a frozen project, I'm afraid it won't be accepted.
So I can publish my refactored version under a different name. Like procxxrv (means procxx-revisited) or procxx-ng (means procxx-new-generation). Or something else if you don't want to see usage of procxx prefix in the name of a derived project.
eao197
commented
4 years ago
We found procxx project several years ago and used it from time to time. In the last usage, I found two important issues:
pipe_t::writein the parent throws, then theflush()method is called from a destructor and thatflush()throws another time. But because the second throw is performed during stack unwinding that throw leads tostd::terminate;execvp()in a child process.To resolve those issues I've made a refactoring of procxx implementation. Now there are methods that accept special
nothrowvalue and do not throw on error. Instances ofstd::error_codeare returned instead (orstd::pair<std::error_code,std::size_t>). Those non-throwing methods are used for cleanup procedures (in destructors, for example).There is also a variant of
process::exec()method that accepts a callback. This callback is called in child/parent processes just after the return fromfork().The current version of my updated procxx fork can be found here (the revisited branch).
I can make a PR, but I think it has a sense only if that PR will be accepted. But because of procxx looks like a frozen project, I'm afraid it won't be accepted.
So I can publish my refactored version under a different name. Like procxxrv (means procxx-revisited) or procxx-ng (means procxx-new-generation). Or something else if you don't want to see usage of procxx prefix in the name of a derived project.