Skip to content

Commit 9486e7b

Browse files
committed
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
1 parent 55fe26a commit 9486e7b

File tree

1 file changed

+8
-1
lines changed

1 file changed

+8
-1
lines changed

src/backend/utils/misc/timeout.c

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -307,7 +307,14 @@ schedule_alarm(TimestampTz now)
307307
* signal is still coming.
308308
*
309309
* Other race conditions involved with setting/checking signal_pending
310-
* are okay, for the reasons described above.
310+
* are okay, for the reasons described above. One additional point is
311+
* that the signal handler could fire after we set signal_due_at, but
312+
* still before the setitimer() call. Then the handler could
313+
* overwrite signal_due_at with a value it computes, which will be the
314+
* same as or perhaps later than what we just computed. After we
315+
* perform setitimer(), the net effect would be that signal_due_at
316+
* gives a time later than when the interrupt will really happen;
317+
* which is a safe situation.
311318
*/
312319
signal_due_at = nearest_timeout;
313320
signal_pending = true;

0 commit comments

Comments
 (0)
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy