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

[eliaskosunen]

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

[klemens-morgenstern]

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

[JeffGarland]

@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]

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

[klemens-morgenstern]

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]

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.