Thanks Cameron
>> Do you mean UNIX "processes" or a more generic "process" like a
>> procedure within the same program/unix-process?
Processes here are not Unix processes ..
My timer functionality is as mentioned below :
I have created a class Timer which registers the timer events based on
their expiration time in a queue ,lowest timeout event is first in the
queue . Here by timeout I mean the time interval in which SIGALRM would be
generated.
I then set the timer for the lowest timeout using setitimer .
In the same class I have defined a handler in the constructor of class
which handles the SIGALRM generated by setitimer.
When handler is called it sets the fd (defined in class) does the required
action and sets the setitimer to the next event in the queue.
This class being used by different processes by creating its objects.
I created a dummy program which uses select and identified when the fd is
set to find out the when the alarm is generated .
But the handler is not getting called at the right time .
I saw that select was interrupted and found that that when handler
returns the process appears to return from the system call indicating the
sys call was interrupted .But in my case it was interrupted without the
handler being called . It was called at a later some random time
What might be the reason for it ??
Regards
Ankit
From: Cameron Simpson <cs@xxxxxxxxxx>
To: General Red Hat Linux discussion list <redhat-list@xxxxxxxxxx>
Date: 10/07/2011 05:11 PM
Subject: Re: Query on signals
Sent by: redhat-list-bounces@xxxxxxxxxx
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
=====-----=====-----=====
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
--
redhat-list mailing list
unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/redhat-list
