Re: Query on signals

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 07Oct2011 14:45, Ankit Mahawar <ankit.mahawar@xxxxxxx> 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@xxxxxxxxxx> 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

-- 
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list


[Index of Archives]     [CentOS]     [Kernel Development]     [PAM]     [Fedora Users]     [Red Hat Development]     [Big List of Linux Books]     [Linux Admin]     [Gimp]     [Asterisk PBX]     [Yosemite News]     [Red Hat Crash Utility]


  Powered by Linux