fork/exec & close file descriptors

[Chris Angelico]

On Thu, Jun 4, 2015 at 6:07 AM,  <random832 at fastmail.us> wrote:
> On Wed, Jun 3, 2015, at 09:32, Chris Angelico wrote:
>> Write an editor that opens a file and holds it open until the user's
>> done with it. Have something that lets you shell out for whatever
>> reason. Then trigger the shell-out, and instantly SIGSTOP the child
>> process, before it does its work - or just have a really heavily
>> loaded system, so it can't get a time slice. Now close the file in the
>> UI, which results in the file being closed in the parent. Right, now
>> let the child run... and there it goes, closing the file.
>
> The parent should be waiting for the child process. If it shouldn't wait
> for the command, then the child process should spawn a grandchild
> process, after closing the file descriptors. This is how the text editor
> I use actually works (more or less. In fact, the way to run a process it
> won't wait for is to run it as a background shell command. If you STOP
> the shell itself, the editor will be stuck waiting.)

Really? I thought forking, execing, and not immediately waiting, was a
standard way to trigger an asynchronous action. My editor lets me
start something and then keep working in the editor, and see the
output from the command when it's ready. (Simple example: A "git push"
might take a long time if the network's slow, and I want to know if it
errors out, but most likely I'll just see the expected messages come
up and that's that.) The parent definitely shouldn't immediately wait
on the child; and it shouldn't disown the child via a second forking
because it wants to report on the child's completion. So no, I don't
think insta-waiting is right in all situations.

ChrisA