Query on signals

Cameron Simpson cs at zip.com.au
Fri Oct 7 11:31:35 UTC 2011


On 07Oct2011 14:45, Ankit Mahawar <ankit.mahawar at tcs.com> wrote:
| I have used setitmer function in C to notify the occurence of an event .
| setitimer function generates a SIGLALRM signal  which I handled through a
| defined handler using signal system call.
| 
| There are multiple processes running and using this handler to handler the
| SIGALRM .
| 
| The handler is defined in a class in a separate file and being used in
| different processes creating local objects.

Do you mean UNIX "processes" or a more generic "process" like a
procedure within the same program/unix-process?

| I noticed that there is a delay in calling the handler for a process ..as
| the signal is generated on time .
| Could anyone help and tell the reason for this behaviour ..

Odd. I'd expect it to be pretty immediate.

| I read that when a process receives a signal the kernel blocks further
| receipt of the signal until the signal handler completes
| So according to this if multiple signals occur on after the other ,both
| gets blocked ?
| If yes then how they get handled at a later time ..

Signals are not really a messaging system. They are more like interrupts.
When they are "blocked" they are discarded. So you do not get to handle
them at a later time.

Generally best practice for a signal handler is to do as _little_ as
possible. Example: set a flag or queue a tiny data packet somewhere (but
avoid memory allocation! not safe during an interrupt!) This minimises
the time window in which the signal is blocked.

The other thing you can do is never have more than one setitmer in play
at a time. Wrap the uses of itimer in a queue of some kind and compute
just the delay to the next event.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

I just kept it wide-open thinking it would correct itself.
Then I ran out of talent.       - C. Fittipaldi




More information about the redhat-list mailing list