Programming

Pipe should flush if you close it after writing to it.

That is correct, it was a typo from me.

Ok looking into this deeper problem seems to be here:

Code:

read(ParentRead, &buf, 1);

Do you see whats wrong with this line?

Which system behaves in this way? To my knowledge, no UNIX-like system sends children a signal when their parent dies. The only thing that happens is that the child is adopted by another process (usually PID 1, usually init).

The only behavior similar to that which you've described is when a child uses Linux's prctl(2) with the PR_SET_PDEATHSIG option. This instructs the kernel to send the chosen signal to that child when its parent dies. However, this is not default behavior; it is non-standard; the signal chosen need not be SIGINT; and the signal value is cleared at every fork(2), so even if a child is set to be notified, its children won't be unless they also call prctl(2).

In this thread's particular case, if the child receives a signal because of its parent's death, it'll likely be a SIGPIPE from the child writing to a broken pipe.

Regards,
Alister

This points to an interesting planning issue: The parent should supervise the children, not the other way around (duh), so the parent can get SIG child if the child goes wrong. I suppose in shell you might even be able to trap that signal.

It is one of the limittions of UNIX piping that something upstream like a sort or find will run on mindless of the loss of processes downstream, until it tries to write something. I even tried writing 0 length messages to the pipe to see if the downstream was still there, but to no avail, or worse, false EOF detection from read() returning zero. So, if it is critical, you need a watchdog or cleanup process. Children can have children, ad infinitum, complicating the process. One way to identify the whole tree is to redirect stderr to a log file, so fuser can tell you who is attached.

You can, but then you get sigchild for every child that quits, including things like mv and cat, not just subshells.

Forgive my stupidity but I don't. I've never used a pipe before so I'm rather ignorant of exactly how interprocess communication works.

---------- Post updated at 11:41 PM ---------- Previous update was at 11:33 PM ----------

I think I see now what you were getting at expl. I was giving the read function the address of an address. Sorry about that. I went into the code, got rid of the ampersand, and rebuilt the program but to no avail. Something is still wrong.

---------- Post updated 10-20-12 at 06:47 PM ---------- Previous update was 10-19-12 at 11:41 PM ----------

Ok, I feel dumb. As it turns out the calls to write to and read from the pipes are working. I forgot that scanf was a blocking function call. Sorry for wasting your time guys, and thank you for all your help.

Yes, but you can keep track of which PIDs you are tracking and just using wait() (not writing signal catchers), can filter child responses for what pids and what return codes you care about. In bash, you can devote a watcher wait subshell for each background process pid $! saved as you launch them, each retrieving the exit code from that child.

It's nothing to do with pipes, it's to do with how arrays work. &buf is overdoing it, it's a pointer already.