search

JeffGarland / liaw2019-process

Repository for initial drafting of boost.process standards paper
MIT License
5 stars 4 forks source link

LEWGI Belfast: add member function requesting orderly shutdown #53

Open eliaskosunen opened 4 years ago

eliaskosunen commented 4 years ago

Implemented with e.g. SIGSTOP or SIGPIPE. Could potentially fall back onto SIGKILL or equivalent if unimplementable on a specific platform.

We were also instructed to bikeshed names for terminate and the functionality described above (called stop for now). Suggestions include request_terminate, or request_PLACEHOLDER, where PLACEHOLDER is whatever terminate is bikeshedded to.

JeffGarland commented 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.

https://www.boost.org/doc/libs/1_70_0/doc/html/boost_process/concepts.html#boost_process.concepts.process.termination

klemens-morgenstern commented 4 years ago

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.

JeffGarland commented 4 years ago

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.

klemens-morgenstern commented 4 years ago

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.