From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Condition variable live lock |
Date: | 2018-01-07 23:38:36 |
Message-ID: | 2437.1515368316@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Actually ... perhaps a better design would be to have
> ConditionVariable[PrepareTo]Sleep auto-cancel any prepared sleep for
> a different condition variable, analogously to what we just did in
> ConditionVariableBroadcast, on the same theory that whenever control
> returns to the other CV wait loop it can re-establish the relevant
> state easily enough. I have to think that if the use of CVs grows
> much, the existing restriction is going to become untenable anyway,
> so why not just get rid of it?
Concretely, as per attached.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
allow-interleaved-cv-sleeps.patch | text/x-diff | 3.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Nikita Glukhov | 2018-01-08 00:22:08 | Re: to_timestamp TZH and TZM format specifiers |
Previous Message | Tom Lane | 2018-01-07 23:34:49 | Re: [HACKERS] [PATCH] Generic type subscripting |