Communicating Between a Parent and Its Children

Communicating between a parent and its children

Your ipc tag says it all. You need to look into inter-process communuication:

• Shared memory.
• Semaphores.
• Pipes.
• Signals.
• Memory-mapped files.
• Sockets.

No doubt there are other possibilities but that's a good start.

How efficient each is depends pretty much on your use case. If you only need to notify a child to do something, signals is probably what I'd use. If you need to transfer some more information between processes, it's probably a good idea to fully specify the requirements.

---

One thing you may want to consider is to bypass all the inter-process stuff altogether and just use threads. At least in Linux, threads are first class citizens to the scheduler. Older UNIXes may have made a distinction (with user-mode threads) but that is not the case with Linux.

I've found that it's simpler to do it that way and your information is automatically shared (keeping in mind you still need to protect shared stuff with mutexes and such).

---

Another possibility if you're already committed to shared memory is to use signals. Assuming you've set aside sections of that memory for each child (and they know where they are), signals are probably the quickest way to notify a bunch of children for parallel work.

If your children just wait around in a select loop with (for example) a 30-second timeout for doing periodic work, a signal will cause it to exit immediately with EINTR. That gives you your efficient CPU usage while still giving immediate response.

communication between parent and child through pipe

To have duplex communication between two processes, you need two pipes:

1. One for parent to child communication;
2. And one for child to parent communication

If you use the same pipe for both, then you can end up with a situation like the child writing something to the pipe, and directly read it back again (and the parent will never see the data).

This could for example happen with e.g.

write(fd[i][1], &sum, sizeof(int));
// ...
// Could read sum that was written just above in the same process
read(fd[i][0], &flag, sizeof(int));

in your child process.

For the example of the write and read calls shown above, you could have something like:

int parent_to_child[2];  // Pipe where parent process write and child reads
int child_to_parent[2];  // Pipe where parent process reads and child writes

pipe(parent_to_child);
pipe(child_to_parent);

// ...

pid = fork();
if (pid == 0)
{
    // Other code...

    // Child writes to parent
    write(child_to_parent[1], &sum, sizeof(int));

    // Child reads from parent
    read(parent_to_child[0], &flag, sizeof(int));

    // ...
}
else
{
    // Other code...

    // Parent reads from child
    read(child_to_parent[0], &sum, sizeof(int));

    // Parent writes to child
    write(parent_to_child[1], &flag, sizeof(int));

    // ...
}

Create 2-way communication between parent and child using pipes in C

fgets reads until it sees a newline (or the buffer is full).

The parent starts out with

fgets(message, 70, stdin);

waiting for a line.

The child outputs

printf("Mr. Stark...");

then also waits:

fgets(input, 70, stdin);

"Mr. Stark..." does not contain a newline. In fact, it's probably not being sent at all and instead buffered inside of stdout, but that could be fixed with fflush(stdout) after printf.

But even then, fgets would still be waiting for a newline that never comes.

Fix:

printf("Mr. Stark...\n");
fflush(stdout);

Is it better to communicate between parent/child components with RXJS or @input/@output

It is much easier and better to use input/output variables then rxjs observables in this case for these reasons:

1. With Input/Output you wont need to create a service and to inject it to both components.
2. There is no need to deal with subscribe/unsubscribe. Angular is doing it for you with input and output variables.

Notice that if you are dealing with sibling components, grandfather component or multiple state sharing then I would advice you to use state sharing with mutual service and behaviorSubject or even use a share manage pattern such as ngrx for more complex scenarios.

---

Related Topics