Home > Archive > Unix Programming > February 2006 > Very fast signal delivery - functional and portable?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Very fast signal delivery - functional and portable?
|
|
| Derek Fountain 2006-02-23, 7:01 pm |
| If I sit in a tight loop delivering signals at maximum speed, like this:
for( i=0; i < 50; i++ ) {
kill( pid, SIGINT );
}
should I expect the destination process to receive all 50 signals and
call it's handler 50 times? Assuming I program the receiving end
properly, of course.
I'd naturally assume that would work, but maybe there's something in
some spec somewhere that says maybe it wouldn't? I'm working on Linux at
the moment, but may need to port to AIX, so is the capability portable?
Also, as an unimportant aside that's just occurred to me, if I change
the 50 to 50,000,000, would I expect to receive them all? Depending on
the handler, that would presumably involve some buffering of pending
signals, and that buffer space must be limited...
| |
| Chris Friesen 2006-02-23, 7:01 pm |
| Derek Fountain wrote:
> If I sit in a tight loop delivering signals at maximum speed, like this:
>
> for( i=0; i < 50; i++ ) {
> kill( pid, SIGINT );
> }
>
> should I expect the destination process to receive all 50 signals and
> call it's handler 50 times? Assuming I program the receiving end
> properly, of course.
Not in the general case. For regular signals, multiple instances of a
signal arrives when that same signal is blocked (like when you're
running the signal handler for that signal, for instance) they may be
dropped.
If you use "realtime" signals, then they will be queued up and will all
be delivered (up to an implementation-defined number of signals in the
queue).
Try reading "man 7 signal" for more information.
Chris
| |
| Lew Pitcher 2006-02-23, 7:01 pm |
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Derek Fountain wrote:
> If I sit in a tight loop delivering signals at maximum speed, like this:
>
> for( i=0; i < 50; i++ ) {
> kill( pid, SIGINT );
> }
>
> should I expect the destination process to receive all 50 signals and
> call it's handler 50 times?
No. There is a latency between the time the signal is sent and the time the
signal is acted upon, and the kernel may have to cope with the same signal many
times before the target processes it. So, all pending signals of the same type
are "collapsed" into a single signal indication to the target. If your target
process cannot be scheduled in time, or cannot complete it's signal handler in
time, it may only receive one signal from your source.
> Assuming I program the receiving end
> properly, of course.
>
> I'd naturally assume that would work, but maybe there's something in
> some spec somewhere that says maybe it wouldn't?
Yup. POSIX. and SUS. and the operational definition of most Unixish systems.
> I'm working on Linux at
> the moment, but may need to port to AIX, so is the capability portable?
>
> Also, as an unimportant aside that's just occurred to me, if I change
> the 50 to 50,000,000, would I expect to receive them all? Depending on
> the handler, that would presumably involve some buffering of pending
> signals, and that buffer space must be limited...
Nope. There is a single bit to indicate "signal(s) of a specific type received
but not delivered". I.e., there is a single bit to indicate SIGINT(s) received
for this process. You can only count two values in that bit: "no signal(s)" or
"signal(s)". There is no queue.
- --
Lew Pitcher
IT Specialist, Corporate Technology Solutions,
Enterprise Technology Solutions, TD Bank Financial Group
(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
iD8DBQFD/ dlOagVFX4UWr64RAlqDAKCU3UTpnFsLg8lqmYFR3
EnEbyIAHACbBhPk
24RO4TmKJZw1IVmiw0GyGXM=
=Ps/Y
-----END PGP SIGNATURE-----
| |
| Nils O. Selåsdal 2006-02-23, 7:01 pm |
| Derek Fountain wrote:
> If I sit in a tight loop delivering signals at maximum speed, like this:
>
> for( i=0; i < 50; i++ ) {
> kill( pid, SIGINT );
> }
>
> should I expect the destination process to receive all 50 signals and
> call it's handler 50 times? Assuming I program the receiving end
> properly, of course.
No, signals doesn't queue (normally), they can get merged.
| |
| Fletcher Glenn 2006-02-23, 7:01 pm |
|
""Nils O. Selåsdal"" <noselasd@asgaard.homelinux.org> wrote in message
news:43fddf6a@news.wineasy.se...
> Derek Fountain wrote:
> No, signals doesn't queue (normally), they can get merged.
For some signals like SIGCHLD, you can recover all of the instances of the
signal. This is because once in the signal handler, you can query the
system for all of the events that generated the signal.
--
Fletcher Glenn
| |
| Derek Fountain 2006-02-24, 3:57 am |
| Derek Fountain wrote:
> If I sit in a tight loop delivering signals at maximum speed, like this:
>
> for( i=0; i < 50; i++ ) {
> kill( pid, SIGINT );
> }
>
> should I expect the destination process to receive all 50 signals and
> call it's handler 50 times? Assuming I program the receiving end
> properly, of course.
Thanks to those who replied. I'm *really* glad I asked - saved myself
some wasted effort here. :o)
|
|
|
|
|