Commit9486e7b

committed

Improve commentary in timeout.c.

On re-reading I realized that I'd missed one race condition in the newtimeout code. It's safe, but add a comment explaining it.Discussion:https://postgr.es/m/CA+hUKG+o6pbuHBJSGnud=TadsuXySWA7CCcPgCt2QE9F6_4iHQ@mail.gmail.com

1 parent55fe26a commit9486e7bCopy full SHA for 9486e7b

File tree

-1

lines changed

-1

lines changed

Lines changed: 8 additions & 1 deletion

Original file line number	Diff line number	Diff line change
`@@ -307,7 +307,14 @@ schedule_alarm(TimestampTz now)`
`307`	`307`	`* signal is still coming.`
`308`	`308`	`*`
`309`	`309`	`* 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.`
`311`	`318`	`*/`
`312`	`319`	`signal_due_at=nearest_timeout;`
`313`	`320`	`signal_pending= true;`

Comments

(0)