On Tue, Jul 16, 2019 at 1:11 AM Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jul 12, 2019 at 11:03 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > I pushed this too. It's a separate commit, because I think there is
> > at least a theoretical argument that it should be back-patched. I'm
> > not going to do that today though, because I doubt anyone is relying
> > on ConditionVariableSignal() working that reliably yet, and it's
> > really with timeouts that it becomes a likely problem.
>
> To make it work reliably, you'd need to be sure that a process can't
> ERROR or FATAL after getting signaled and before doing whatever the
> associated work is (or that if it does, it will first pass on the
> signal). Since that seems impossible, I'm not sure I see the point of
> trying to do anything at all.
I agree that that on its own doesn't fix problems in <some
non-existent client of this facility>, but that doesn't mean we
shouldn't try to make this API as reliable as possible. Unlike
typical CV implementations, our wait primitive is not atomic. When we
invented two-step wait, we created a way for ConditionVariableSignal()
to have no effect due to bad timing. Surely that's a bug.
--
Thomas Munro
https://enterprisedb.com