From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Remove return values of ConditionVariableSignal/Broadcast. |
Date: | 2018-01-06 01:33:31 |
Message-ID: | E1eXdMZ-0004tx-2s@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Remove return values of ConditionVariableSignal/Broadcast.
In the wake of commit aced5a92b, the semantics of these results are
a bit squishy: we can tell whether we signaled some other process(es),
but we do not know which ones were real waiters versus mere sentinels
for ConditionVariableBroadcast operations. It does not help much that
ConditionVariableBroadcast will attempt to pass on the signal to the
next real waiter, because (a) there might not be one, and (b) that will
only happen awhile later, anyway. So these results could overstate how
much effect the calls really had.
However, no existing caller of either function pays any attention to its
result value, so it seems reasonable to just define that as a required
property of a correct algorithm. To encourage correctness and save some
tiny number of cycles, change both functions to return void.
Patch by me, per an observation by Thomas Munro. No back-patch, since
if any third parties happen to be using these functions, they might not
appreciate an API break in a minor release.
Discussion: https://postgr.es/m/CAEepm=0NWKehYw7NDoUSf8juuKOPRnCyY3vuaSvhrEWsOTAa3w@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/ccf312a4488ab8bb38dfd87168bf8915045d1a82
Modified Files
--------------
src/backend/storage/lmgr/condition_variable.c | 32 +++++++++------------------
src/include/storage/condition_variable.h | 4 ++--
2 files changed, 13 insertions(+), 23 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-01-06 01:39:46 | Re: pgsql: pg_upgrade: simplify code layout in a few places |
Previous Message | Tom Lane | 2018-01-06 00:42:57 | pgsql: Reorder steps in ConditionVariablePrepareToSleep for more safety |