search

JeffGarland / liaw2019-process

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

LEWGI Belfast: `std::process` constructor should take a callback called by the destructor #50

Open eliaskosunen opened 4 years ago

eliaskosunen commented 4 years ago

Note, that this direction has not been approved by SG1, which is still undecided on the matter.

klemens-morgenstern commented 4 years ago

Sounds weird to me. Why not just write a small wrapper? what's the background?

JeffGarland commented 4 years ago

@eliaskosunen - are the LEWGI wiki notes up? The discussion is rooted in discussion of this part of the paper:

6.4 process destructor should not terminate SG1 in Cologne discussed the behavior of the process destructor at length. Originally, it was proposed, that the program would terminate if wait had not been called, like std::thread does. The over arching backdrop of SG1 discussion was, that std::thread destructor calling terminate was a poor design choice, that was not to be repeated (see std::jthread). The authors would like committee guidance and discussion of some possible options, including: • call process::terminate on child • call wait by default in the destructor • add some sort of request_stop interface to process to mirror std::jthread api • a constructor option to pick from pre-defined behaviors like wait or detach Note that calling wait in the destructor can also cause poor behavior if the child process never exits. This, however, is similar to the problem with jthread::join, if the user fails to implement cooperative shutdown logic.

eliaskosunen commented 4 years ago

LEWGI minutes are up. The issues I created are copied from the summary from the GitHub issue: https://wg21.link/p1750/github

klemens-morgenstern commented 4 years ago

We can do that, but I would then template it. In which case why not just subclass std::process? I don't get it.

The default behavior must be terminate, since (unlike std::jthread) we don't even know what's happening inside the subprocess.

klemens-morgenstern commented 4 years ago

Would more examples that illustrate how the solutions are diverse help?

It seems to me that this is largely motivated by jthread, which makes people consider a bit sensitive towards a terminate, even though it's terminating another process in our case.