On 06/09/10 17:18, Tom Lane wrote:
> Heikki Linnakangas<heikki.linnakangas@enterprisedb.com> writes:
>> I think we have just a terminology issue. What you're describing is
>> exactly how it works now, if you just s/InitLatch/AcquireLatch.
>
> No, it isn't. What I'm suggesting requires breaking InitLatch into two
> operations.
>
>>> We also need to define the semantics of SetLatch
>>> on an unowned latch --- does this set a signal condition that will be
>>> available to the next owner?
>
>> At the moment, no. Perhaps that would be useful, separating the Init and
>> Acquire operations is needed to make that sane.
>
> Exactly. I'm not totally sure either if it would be useful, but the
> current design makes it impossible to allow that.
Ok, I've split the Init and Acquire steps into two.
> BTW, on reflection the AcquireLatch/ReleaseLatch terminology seems a bit
> ill chosen: ReleaseLatch sounds way too much like something that would
> just unlock or clear the latch. Perhaps OwnLatch/DisownLatch, or
> something along that line.
Yeah, I see what you mean. Although, maybe it's just me but Own/Disown
looks ugly. Anyone have a better suggestion?
Here's an updated patch, with all the issues reported this far fixed,
except for that naming issue, and Fujii's suggestion to use poll()
instead of select() where available. I've also polished it quite a bit,
improving comments etc. Magnus, can you take a look at the Windows
implementation to check that it's sane? At least it seems to work.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com