I suggest you "man 7 signal" and "man sigaction".
However, it sounds like what you're trying to do is probably best accomplished without signals; possibly better left to something like an event library (google libevent).
edit: to be more helpful; let me break down your post:
Quote:
Originally Posted by
anktim
Hi
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 .
Fine.
Quote:
Originally Posted by
anktim
The handler is defined in a class in a separate file and being used in
different processes creating local objects.
Take a long and hard read about async signal safe functions. You may not want to do as much work as you're doing in that signal handler.
Quote:
Originally Posted by
anktim
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 ..
Nope...but I'm not surprised the timer may not be as precise as you want.
Quote:
Originally Posted by
anktim
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 ..
Regards,
Ankit
True, depending on how you install the signal handler. And, since signals don't have to be delivered, if it's blocked and another signal is queued up and delivered, it could be ignored. In other words, if I run a process and just fire the alarm signal into it (kill -alrm <pid>) over and over rapidly, it's not going to queue up all those signals and then call your handler all those times. It'll queue up one (maybe) and drop all the rest. Make sense?