You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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::write
in 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
nothrow
value and do not throw on error. Instances ofstd::error_code
are 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.
The text was updated successfully, but these errors were encountered: