Programming

You could also try a message queue or domain socket. While these are a bit more complex than a pipe, they can be done bi-directionally and therefore can make this "do this; ok done" protocol a bit more simple than semaphores and signals.

In my opion, an easier more natural way of doing this is to use the select statement to wait on the commands to come in from the pipe and then communicate back to the parent (who also uses select) when the command has been completed. This is, in my opinion, a much better and predictable way of coding this. Plus, it has the advantage of not being capable of "losing" signals because of the fact that the pipe will continue to be readable until all commands are read off it.

For simplicity, you could use a single pipe to each child, have the parent write the command down the pipe, then the child (blocking in a select) would read it and signal back to the parent (either via another pipe, or with a bidirectional IPC mechanism such as a domain socket).

The simplest way I'd attack this is as follows:

Create a pipe which will be used to talk back to the parent. We'll call this pipe "U" (for upstream to the parent)

Create a pipe to each of the n children and fork them. (Remember to close the write end in the child code after the fork). We'll call this pipe "D" (for downstream from the parent)

Close the read end of the U in each child. Then go into an infinite "select" statement loop waiting for that childs' "D" to become readable.

Close the read end of EACH D you created in the parent.

While all that closing isn't really needed, it is recommended as a real application wouldn't want to leave dangling references to file descriptors it doesn't need.

At this point you can do the follow:

In the parent:
Send a command to the appropritate "D" pipe from the server.
Enter a select loop waiting for the child to send the "done" response back on "U"
Read the response.
Restart this process for the next child.

In the child:
Read the command, handle it, then write "done" to the parent's "U".

And that's pretty much it.

At the end you may want the parent to send "termination" commands down each "D" to kill off the children, or just use the kill command to do it explicitely. You'll also probably want to investigate the SIGCHLD signal as you may want to set it to be ignored to keep from getting zombie (or defunct) processes.

Anyway, just another idea. Personally, I don't like using signals to alert a process to do something given their potential for loss and the fact that their reception will intercept your code's stack and therefore the work they can do is very limited.

When you write a value to a pipe, when is the value removed? Also does anyone have same code of creating pipes and assigning them to child processes?
Thanks,
FG

This is getting slightly offtopic, but what the heck, there are not many posts in this forum anyway...

> In my opion, an easier more natural way [...]

One could also argue that signals would be more natural, because the problem solved by forumGuy does not require a means to carry data; It's only the notification that is desired, since there are no commands other than ``write PID''. Signal loss need not be a problem either, for the reasons I mentioned earlier.
But as you said, this is a matter of personal taste and preference.

> their reception will intercept your code's stack and therefore the work they can do is very limited.

Actually, it's not the stack that limits the usability of signal handlers. Unless you specify your own stack for signal handling (using the sigaltstack() function), its use of memory will be much the same as that of a simple nested function call, including the usual automatic expansion of stack space if its current end is reached.

The real problem is that static data might be corrupted if a signal is posted while the normal path of execution uses and relies on static data that will also be accessed by the signal handler. If write access of variables also reda or written by signal handlers is not protected by blocking signals (analogous to the way you have to block interrupts in the top half of a device driver so it does not interfere with updates from an interrupt handler), interolerable race conditions will result (there are also tolerable race condition, but that's another story).

All variables have to be volatile-qualified to begin with. If the normal path of execution is in the process of updating a shared resource, the signal handler might find it in an incosistent state. This is, however, a solvable problem, as I said: Block signals as needed and you can write away.

Unsolvable problems arise when the standard C library comes into play (this is the real reason why signal handlers are not very powerful). A function you intend to call from within a signal handler must be guaranteed to be reentrant, because otherwise a code path running this function might be using static data. If a signal calls the same function, it will invariably corrupt this static data and your program will break.

Even if the function happens to be unused at a certain point, the behavior of calling it from within a signal handler is still undefined and should not be relied on. The POSIX list of functions that are guaranteed to be called safely from a signal handler is very short. To begin with, it excludes ALL Pthreads-related functions, so you cannot e.g. signal a condition variable and unlock a mutex from within a signal handler.
-------------snip--------------

> When you write a value to a pipe, when is the value removed?

As soon as a reader of the pipe read()'s the data.

> Also does anyone have same code of creating pipes and assigning them to child processes?

Code:

int     fds[2];
pid_t   pid;
if (pipe(fds) == -1) {
        /* Handle error */
}

if ((pid = fork()) == -1) {
        /* Handle error */
} else if (pid == 0) {
        char    buf[128];
        int     rc;
        close(fds[1]);
        if ((rc = read(fds[0], buf, sizeof buf - 1)) == -1) {
                /* Error */
        } else if (rc == 0) {
                /* Other end closed by parent */
        } else {
                buf[rc] = 0;
                puts(buf);
        }
        close(fds[0]);
} else {
        close(fds[0]);
        if (write(fds[1], "hello world", sizeof "hello world") == -1) {
                /* Error */
        }
        close(fds[1]);
}

I didn't test this, but something along the lines should work... Again, I refer you to the pipe() and read() and write() manual help pages in case you need more information.

Thank you for the sample code, I was discussing pipes with one of my colleagues and it is seems that when a read is being performed on a pipe the OS performs a blocking operation or a blocking operation takes place and because of this, all the processes can be coordinated amongst themselves to perform the tasks that were previously outlined. Can someone shed some light on this if possible.
Thanks,
FG

You cannot share a single pipe among all children and the parent in this case, because it's impossible to direct the data to a particular child, so the reader of next message will be picked more or less at random out of the bunch of children blocked on the pipe.
You would have to have one pipe per child.

Each child can block on its pipe and wait for a message by the parent. The problem here is that a pipe is generally uni-directional, i.e. both descriptors for I/O permit only input or output, but not both. Some pipe implementations do support bi-directional transfers, but this feature is not specified by the various POSIX and UNIX standards and should not be relied on.

It follows that you will need an additional means to notify the parent of the completition of command interpretation and execution, such as an additional pipe, or a semaphore, or a signal handler, or a message queue, or ...

My mistake, I forgot to mention the most important thing, the scheme has to change, it cannot be a master slave relationship. So once the children are created the parent either waits or exits without doing anything else. The children have to coordinate and achieve the following output:
% a.out 5 3 temp

should result in temp having the following contents:
1
2
3
4
5
1
2
3
4
5
1
2
3
4
5
So if I can set up a pipe from P1 (Process1) to P2 form P2 to P3 ...Pn-1 to Pn and then another pipe for each process (each process has two pipes) to the output file, is there a way to coordinate this? Also when you say "Each child can block on its pipe" can you expand a bit, maybe an example.
Thanks,
FG

> My mistake, I forgot to mention the most
> important thing, the scheme has to change,
> it cannot be a master slave relationship.

Why not?


> So if I can set up a pipe from P1 (Process1)
> to P2 form P2 to P3 ...Pn-1 to Pn and then
> another pipe for each process (each process
> has two pipes) to the output file, is there a
> way to coordinate this?

Two processes can only communicate through a pipe if it was created by a common parent (or one of them is the parent itself). The pipes have to be set up by the parent, and you must also make them aware of their position in this line of pipes, for example by writing it to a counter before performing a fork().

Also, if you choose to use pipes after all, you don't have to communicate the results back again. The final child in the line could write to the first pipe so you get a circle.

> Also when you say "Each child can block on
> its pipe" can you expand a bit

What's to expand? I repeated what you said in your post: That the read will block if there is no data.

I think it's time for you to research the rest of your solution on your own now.