Unix process synchronization without pthreads/sempahores, signals?

Question

Hello, I am attempting to write a program that doesn't use pthreads or semaphore libraries. I want to do some synchronization with signals. I have read about them in a few Unix books, but I still don't quite get it. I wrote up some mock program design/code, this isn't my program but it gives an idea of how I am trying to organize processes/signals. Does this seem like a plausible solution?

Program Flow:

Main forks a random number of times, and executes "program" in each child. The program assigns a value to the child, 1 or 2 (such as input or output etc.).

I want a way to synchronize these children. I thought using signals could be possible, and from what I read I would want to do something like:

If child == 1, send parent (main) SIGUSR1, else if child == 2 send parent (main) SIGUSR2. When the parent services the signal, then end.

Now back in main I want to organize these incoming signals. I would only accept one type at a time, so if a child sends me SIGUSR1, I will block all SIGUSR2s, or if a child sends me SIGUSR2 first then I block all SIGUSR1s. Main will receive the signal and service all signals of that type until there are no more of that type, then it will check/unblock the other type and service any of that type if they exist, else main will wait for more signals.

Does this seem like a proper use of signals and is this even possible with signals?

Thanks!

Answer 1

You don't say why you want to use signals. Are you just trying to figure out how signals work?

Does this seem like a proper use of signals and is this even possible with signals?

I wouldn't approach the sort of design you've presented with signals in mind. You don't say what the children are doing, but I might use pipes, or sockets, or perhaps message queues.

If you can add some information about your high-level goals, I may be able to offer you some better direction.