Re: Introduce timeout capability for ConditionVariableSleep

From: Shawn Debnath <sdn(at)amazon(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Introduce timeout capability for ConditionVariableSleep
Date: 2019-07-12 06:08:13
Message-ID: 20190712060813.GA99189@f01898859afd.ant.amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)munro(at)gmail(dot)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)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gavin Flower 2019-07-12 06:13:26 Re: Unknown type name bool
Previous Message Kyotaro Horiguchi 2019-07-12 06:05:27 Re: [RFC] [PATCH] Flexible "partition pruning" hook