Open eliaskosunen opened 4 years ago
I like the name request_stop
or stop
. The former matches whats in the jthread
which may be a good or bad thing.
And yes, there's a platform related problem. To quote boost.process docs:
Usually the first approach is to signal an exit request, but windows - unlike posix - does not provide a consistent way to do this. Hence this is not part of the library and only the hard terminate is.
If we want to do that in a reliable, standard way we need it on both sides, i.e. have a stop-token in the child process. Showstopper for me.
Well we can't have a stop in the client because obviously we don't necessarily control the client -- it might be an executable we didn't create. Even if we control the client if we're using some sort of parent <-> child pipe to control we can't guarantee that the program is correct and doesn't hang in a deadlock on shutdown.
So my take from the committee discussion is that we obviously can't design a facility that stops all child bad behavior, but they would like to provide the 'nice shutdown' option if available. We might think of handling this without adding to the api here as we have to deal with the comments about destructor behavior anyway -- possibly by giving the user the ability to inject a shutdown handler at construction.
We could have an interrupt request, but i think you will not be able to tell if the child process actually handles it on windows. While on Linux there is a strong guarantee that the process either handles the request or gets shut down.
I think it's a bad idea, especially since it can easily be added using the 'native_handle'. Iean this is really what it's for.
Implemented with e.g.
SIGSTOP
orSIGPIPE
. Could potentially fall back ontoSIGKILL
or equivalent if unimplementable on a specific platform.We were also instructed to bikeshed names for
terminate
and the functionality described above (calledstop
for now). Suggestions includerequest_terminate
, orrequest_PLACEHOLDER
, wherePLACEHOLDER
is whateverterminate
is bikeshedded to.