Commit 9486e7b6 authored by Tom Lane's avatar Tom Lane

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
parent 55fe26a4
...@@ -307,7 +307,14 @@ schedule_alarm(TimestampTz now) ...@@ -307,7 +307,14 @@ schedule_alarm(TimestampTz now)
* signal is still coming. * signal is still coming.
* *
* Other race conditions involved with setting/checking signal_pending * 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_due_at = nearest_timeout;
signal_pending = true; signal_pending = true;
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment