From 9486e7b666fd113f043d5f091fd42bc1ef72acd8 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Wed, 6 Jan 2021 22:02:35 -0500 Subject: Improve commentary in timeout.c. On re-reading I realized that I'd missed one race condition in the new timeout code. It's safe, but add a comment explaining it. Discussion: https://postgr.es/m/CA+hUKG+o6pbuHBJSGnud=TadsuXySWA7CCcPgCt2QE9F6_4iHQ@mail.gmail.com --- src/backend/utils/misc/timeout.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'src/backend/utils/misc/timeout.c') diff --git a/src/backend/utils/misc/timeout.c b/src/backend/utils/misc/timeout.c index 88139ab82b6..95a273d9cfb 100644 --- a/src/backend/utils/misc/timeout.c +++ b/src/backend/utils/misc/timeout.c @@ -307,7 +307,14 @@ schedule_alarm(TimestampTz now) * signal is still coming. * * Other race conditions involved with setting/checking signal_pending - * are okay, for the reasons described above. + * are okay, for the reasons described above. One additional point is + * that the signal handler could fire after we set signal_due_at, but + * still before the setitimer() call. Then the handler could + * overwrite signal_due_at with a value it computes, which will be the + * same as or perhaps later than what we just computed. After we + * perform setitimer(), the net effect would be that signal_due_at + * gives a time later than when the interrupt will really happen; + * which is a safe situation. */ signal_due_at = nearest_timeout; signal_pending = true; -- cgit v1.2.3