Assuming SIGALRM is blocked, a SIGALRM is pending and the alarm is reset
with a new alarm call, what (if anything) happens to the pending signal?
Due "the precautionary principle", all my alarm calls in a certain piece
of code are presently wearing facemas^w^w followed by switching the
signal action to SIG_IGN and back in order to get rid of one which might
have been pending by the time the alarm call was made. At least theoretically, that's unsafe because the alarm which was just set up
could have been expired before the second syscall.
In article <87a6r0msvh.fsf@doppelsaurus.mobileactivedefense.com>,
Rainer Weikusat <rweikusat@talktalk.net> writes:
Assuming SIGALRM is blocked, a SIGALRM is pending and the alarm is reset
with a new alarm call, what (if anything) happens to the pending signal?
Due "the precautionary principle", all my alarm calls in a certain piece
of code are presently wearing facemas^w^w followed by switching the
signal action to SIG_IGN and back in order to get rid of one which might
have been pending by the time the alarm call was made. At least
theoretically, that's unsafe because the alarm which was just set up
could have been expired before the second syscall.
Except for cases of SIGCHLD generated by the OS (which is an exception because one could have multiple child processes exit, and if depending
on SIGCHLD rather than wait() to find out, still need to know about
each), signal delivery is generally NOT reliable when multiple
instances of the same signal are pending;
A further complication, what happens if the system clock is set
forward with an alarm pending, is it delivered based on the
new wall clock time, or unaffected and still the same amount of time after it was issued?
Assuming SIGALRM is blocked, a SIGALRM is pending and the alarm is reset
with a new alarm call, what (if anything) happens to the pending signal?
Due "the precautionary principle", all my alarm calls in a certain piece
of code are presently wearing facemas^w^w followed by switching the
signal action to SIG_IGN and back in order to get rid of one which might
have been pending by the time the alarm call was made. At least theoretically, that's unsafe because the alarm which was just set up
could have been expired before the second syscall.
Rainer Weikusat <rwei...@talktalk.net> writes:
Assuming SIGALRM is blocked, a SIGALRM is pending and the alarm is reset with a new alarm call, what (if anything) happens to the pending signal?
Due "the precautionary principle", all my alarm calls in a certain pieceParagraph above is not entirely correct: Prior to reprogramming the
of code are presently wearing facemas^w^w followed by switching the
signal action to SIG_IGN and back in order to get rid of one which might have been pending by the time the alarm call was made. At least theoretically, that's unsafe because the alarm which was just set up
could have been expired before the second syscall.
alarm time, I'm doing an alarm(0) to kill a possibly still running alarm followed by changing the signal disposition to SIG_IGN and back to get
rid of a possibly pending SIGALRM, followed by setting the new alarm.
AFAICT, this procedure is correct and SUS doesn't say anything re: What happens to a pending SIGALRM when the alarm time is changed.
Judging
from a cursory look at the Linux code, it doesn't seem to do anything
about this despite receiving an "old" SIGALRM after a new alarm was set
seems singularly useless (to me).
On Friday, March 19, 2021 at 6:37:30 AM UTC-9, Rainer Weikusat wrote:
Rainer Weikusat <rwei...@talktalk.net> writes:
Assuming SIGALRM is blocked, a SIGALRM is pending and the alarm is reset >> > with a new alarm call, what (if anything) happens to the pending signal?
Paragraph above is not entirely correct: Prior to reprogramming the
alarm time, I'm doing an alarm(0) to kill a possibly still running alarm
followed by changing the signal disposition to SIG_IGN and back to get
rid of a possibly pending SIGALRM, followed by setting the new alarm.
Given the context of "already blocked SIGALRM", this seems like the correct procedure to me.
(For some simpler cases, instead of blocking it before the critical section it may
be simpler to call alarm(0) and then see whether the alarm actually triggered and skip the processing if it did, but if there are prerequisites that have to be
handled before the alarm can be safely canceled then that won't be reliable and
I agree your block/cancel/ignore/catch/set is the right sequence.)
AFAICT, this procedure is correct and SUS doesn't say anything re: What
happens to a pending SIGALRM when the alarm time is changed.
It doesn't say anything because changing the alarm time has no effect on pending SIGALRM signals.
Judging from a cursory look at the Linux code, it doesn't seem to do
anything about this despite receiving an "old" SIGALRM after a new
alarm was set seems singularly useless (to me).
That was the behavior of all the existing UNIX systems when POSIX was written, no?
Philip Guenther <guenther@gmail.com> writes:
On Friday, March 19, 2021 at 6:37:30 AM UTC-9, Rainer Weikusat wrote:
Rainer Weikusat <rwei...@talktalk.net> writes:
Assuming SIGALRM is blocked, a SIGALRM is pending and the alarm is reset >>> > with a new alarm call, what (if anything) happens to the pending signal?
[...]
Paragraph above is not entirely correct: Prior to reprogramming the
alarm time, I'm doing an alarm(0) to kill a possibly still running alarm >>> followed by changing the signal disposition to SIG_IGN and back to get
rid of a possibly pending SIGALRM, followed by setting the new alarm.
Given the context of "already blocked SIGALRM", this seems like the correct >> procedure to me.
(For some simpler cases, instead of blocking it before the critical section it may
be simpler to call alarm(0) and then see whether the alarm actually triggered
and skip the processing if it did, but if there are prerequisites that have to be
handled before the alarm can be safely canceled then that won't be reliable and
I agree your block/cancel/ignore/catch/set is the right sequence.)
That's not possible in this case: I'm using sigwait(info) to wait for
three possible events (termination of a task running in a forked
process/ SIGCHLD, timeout/ SIGALRM, user request to abort it/
SIGINT). Assuming a timeout or an abort request occurs, a SIGTERM is
being sent to the process. The alarm is then reprogrammed (using a
shorter interval) to a second timeout triggering a SIGKILL.
AFAICT, this procedure is correct and SUS doesn't say anything re: What
happens to a pending SIGALRM when the alarm time is changed.
It doesn't say anything because changing the alarm time has no effect on
pending SIGALRM signals.
[...]
Judging from a cursory look at the Linux code, it doesn't seem to do
anything about this despite receiving an "old" SIGALRM after a new
alarm was set seems singularly useless (to me).
That was the behavior of all the existing UNIX systems when POSIX was
written, no?
UNIX is older than me (although not much), hence "I have no idea" :-).
It just not particularly sensible: The next SIGALRM received by a process >after a call to alarm (or similar) returned should correspond to the
most recently programmed alarm.
Note that the ability to block/mask/hold signals is relatively recent in the Unix timeline and was part of the POSIX 1003.4 real-time extensions
that brought us pthreads.
Scott Lurndal wrote:
Note that the ability to block/mask/hold signals is relatively recent in theNo, you must be thinking of signal queueing and siginfo_t.
Unix timeline and was part of the POSIX 1003.4 real-time extensions
that brought us pthreads.
Blocking/masking with sigprocmask() has been in POSIX.1 since the
original 1988 standard.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 308 |
Nodes: | 16 (2 / 14) |
Uptime: | 92:59:34 |
Calls: | 6,923 |
Calls today: | 1 |
Files: | 12,382 |
Messages: | 5,434,104 |