IPC Mechanisms

[korg]

 1  static volatile sig_atomic_t sigreceived = 0;
 2
 3  sigset_t maskall, maskmost, maskold;
 4  int signum = SIGUSR1;
 5
 6  sigfillset(&maskall);
 7  sigfillset(&maskmost);
 8  sigdelset(&maskmost, signum);
 9  sigprocmask(SIG_SETMASK, &maskall, &maskold);
10  if (sigreceived == 0)
11     sigsuspend(&maskmost);
12  sigprocmask(SIG_SETMASK, &maskold, NULL);

Consider the above code. Text i have says that this is the correct way to wait for SIGUSR1 signal , but i am unable to wrap my head around it.


so maskall -> all signals , maskmost-> all except sigusr1

Can some one explain what does this do?

sigprocmask(SIG_SETMASK, &maskall, &maskold);


and why is this :

sigsuspend(&maskmost);

Shouldn't the mask of sigsuspend contain only signal SIGUSR1?

Cheers!

[jsmith]

SIG_SETMASK means to "mask out" -- or block -- any signal in the given set. ie, "I'm NOT
interested in the following signals..."

Line 9 tells the kernel that you want to block every signal that is blockable, so in other words, you
don't want to receive any signal.

Presumably, it was possible for the program to receive a signal that would cause sigreceived to
get set even before line 9 executed, so line 10 checks to see if a signal was already received.
If it wasn't, then line 11 tells the kernel to suspend the process until it receives a signal that it
is masked in the parameter. The only signal not masked in maskmost is SIGUSR1. Therefore,
sigsuspend() waits until SIGUSR1 is received.

Line 12 then restores the process' signal mask to what it was before line 9 changed it.

More info can be found if you man sigprocmask and sigsuspend.

[korg]

Thanks jsmith! I still have this doubt ... SIG_SETMASK does both block & populate the out prameter ? i.e.
sigprocmask(SIG_SETMASK, &maskall, &maskold);

and if this is done , it sets the new mask and unblocks the pending signals?

sigprocmask(SIG_SETMASK, &maskold, NULL);

And why is this required ? Since i understand, sigsuspend resets the signal mask as originally it was.

Cheers!

[korg]

I got it!

Early on all signals are blocked , then all signals except sigusr1 is blocked, on receipt the state is restored to the last configuration i.e all signals blocked. So we explicitly need to restore the old state.

[jsmith]

Line 12 undoes line 9.

The sig mask is changed three times explicitly by the program: lines 9, 11, and 12.

[korg]

^_^

I have a confusion with pipe. Is it only that a parent can write and the child can read?

Can't a child write to fd[1] and parent reads from fd[0] (traditions aside :P) ; i.e. with descriptors open at both processses.

http://jan.newmarch.name/ProgrammingUnix/ipc/lecture.html#Pipes

This says we can run into unpredictable behaviour... Can some one please list out an example ?

[jsmith]

No, both can write and both can read. Think of it as a two-lane highway. Cars (data)
can flow in one directly only per lane, but there are two lanes, so you can achieve
bidirectional data.

[korg]

*Cyberhugs jsmitj*

I am trying to understand which IPC mechanism should be preferred over another. I have read up a deal of it on Beej's guide & a book i picked up recently (UNIX Systems Programming: Communication, Concurrency and Threads).

While each of these books do a wonderful job of explaining of how to setup & use each of the IPC mechanisms; they do not touch on performance implications of the same.The interwebs is not helping either.

Well it's obvious that a mechanism like socket will be used if the system is distributed , but what is the case when the processes reside on the same system?

I.e Mainly , i am looking for advantages/disadvantages between the following mechanisms :

- Named Pipes
- Message Queues
- Shared Memory
- Local Sockets

I would love it if you guys can give some practical scenarios where you have encountered them & any reason why one should be preferred over another. All examples i have come across are typical process A writes int and B reads it.

Also apart from access to shared memory/hardware resources , is there any other reason where semaphores are used?

[jsmith]

(System V) message queues should be avoided simply because whereas everything
else in UN*X land is a file descriptor, message queues are accessed through message
queue IDs and not file descriptors.

I tend to avoid shared memory and named pipes because both have state that is
external to the program (ie, if the program dies, the state remains).

I prefer sockets because I can use all the "standard" system calls on them -- select, read,
write, close, etc.