Re: Introduce timeout capability for ConditionVariableSleep - Mailing list pgsql-hackers

From Shawn Debnath
Subject Re: Introduce timeout capability for ConditionVariableSleep
Date
Msg-id 20190712060813.GA99189@f01898859afd.ant.amazon.com
Whole thread Raw
In response to Re: Introduce timeout capability for ConditionVariableSleep  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: Introduce timeout capability for ConditionVariableSleep  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Tue, Jul 09, 2019 at 11:03:18PM +1200, Thomas Munro wrote:
> On Sun, Jul 7, 2019 at 3:09 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> > +               /* Timed out */
> > +               if (rc == 0)
> > +                       return true;
> 
> Here's a version without that bit, because I don't think we need it.

This works. Agree that letting it fall through covers the first gap.

> > That still leaves the danger that the CV can be signalled some time
> > after ConditionVariableTimedSleep() returns.  So now I'm wondering if
> > ConditionVariableCancelSleep() should signal the CV if it discovers
> > that this process is not in the proclist, on the basis that that must
> > indicate that we've been signalled even though we're not interested in
> > the message anymore, and yet some other process else might be
> > interested, and that might have been the only signal that is ever
> > going to be delivered by ConditionVariableSignal().
> 
> And a separate patch to do that.  Thoughts?

I like it. This covers the gap all the way till cancel is invoked and it 
manipulates the list to remove itself or realizes that it needs to 
forward the signal to some other process.

Thanks Thomas!

-- 
Shawn Debnath
Amazon Web Services (AWS)



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: [RFC] [PATCH] Flexible "partition pruning" hook
Next
From: Gavin Flower
Date:
Subject: Re: iso-8859-1 type name bool