Should Process::drop wait for the child?

[alexcrichton]

Currently the Drop implementation for Process invokes wait. Apart from blocking in destructors, this could also lead to unexpected results if the desire was to fork off a daemon.

Should we block in wait? If not, who cleans up the resources?

Nominating.

[thestinger]

Modern daemons are not supposed to fork, so I don't think it needs to be taken into account in Rust's design. They're a normal non-forking process, and can be augmented to notify the init system of readiness or make use of socket activation.

There's absolutely no way for forking daemons to avoid race conditions. They can be reliably killed via control groups on Linux, but there's no non-racy/non-polling way to do supervision.

[pnkfelix]

Assigning P-backcompat-libs, 1.0 milestone.

[alexcrichton]

@glandium comments in #14410

My use-case is that i want to spawn a (detached) subprocess that survives the parent process. The equivalent of doing "command&" in a shell script.

Per IRC discussion:
forget() it when you're done with it?
it probably shouldn't wait in the destructor
should probably have a separate wait method
afaik we've been trying to avoid blocking destructors
glandium: it could be marked #[must_use] and only be destroyed with a wait or detach method, for example

[alexcrichton]

We talked about this in today's meeting. Invoking wait in drop is required to prevent resource leaks, but having a child outlive the parent is also an important use case. I will open a separate issue on the fix we discussed.

[alexcrichton]

This issue was nominated for the 1.0 milestone, and I have closed it because our resolution was to add a method to explicitly allow a child to outlive the parent. This method can be added in a backwards compatible fashion, so the new issue no longer needs to be on the 1.0 backcompat-lang milestone.