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