Open klemens-morgenstern opened 3 years ago
An additional feature of the second approach is that we could remove this from the initial paper, since it's just another class. I'll give it a try in my reference implementation.
OTH: There has to be clear ownership of the process object, because otherwise there might be a mismatch on the exit_code
. Having a seperate object might introduce a few sharp edges.
On a related note, I don't know if you've been following this but this paper is the currently agreed design for executors that is being pushed for c++23 related to the networking TS. I don't know how much of it is implemented as of yet by Chris (I know he's tracking it) or others. http://wg21.link/p0443 -- anyway we need to fit into this.
I just added async_wait as a member like this: https://github.com/klemens-morgenstern/process/blob/master/test/wait_exit.cpp#L33
I think we can leave it for now, but maybe mention the alternative when we discuss this.
I have been marginally aware of this paper, but the nice thing is that we only really have to design the async_wait
. The pipes
are basically a copy of any streaming IO object like tcp::sockets
so that we don't need to design much there.
@klemens-morgenstern where would we find the writeup?
Arrg, I responed to the wrong email, so that went to github. Will mail it out again in a minute.
Basesd on #57 i would argue, that we need an
async_wait
functionality.One design question is if we turn the
process
into a waitable object, like so:The downside is that we need to pass the executor into the
async_wait
function, which is inconsisten with the networking TS design. Secondly, theprocess
class will need data members that hold theasync wait
implementation, currentlyasio::signal_set
andobject_handle
.Alternatively use an object holding all the asio stuff named
process_waitee
or something.The second approach has a clearer design with an io object, but has a sharing problem. That is: in order for the
process
object to have the rightexit_code
, thewaitee
would need to keep a reference to it, or make the internalexit_code
ashared_pointer
. If not, theprocess
might not only have the wrong exit code, but might also be unaware that the process ended. Thus the first approach has a slightly unusual function signature, but the second solution introduces a bunch of complexity.