On Mon, Sep 26, 2016 at 1:46 PM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> If the class really is strictly implied by the WaitEventIdentifier,
> then do we really need to supply it everywhere when calling the
> various wait functions? That's going to be quite a few functions:
> WaitLatch, WaitLatchOrSocket, WaitEventSetWait for now, and if some
> more patches out there have legs then also ConditionVariableWait,
> BarrierWait, and possibly further kinds of wait points. And then all
> their call sites will have have to supply the wait class ID, even
> though it is implied by the other ID. Perhaps that array that
> currently holds the names should instead hold { classId, displayName }
> so we could just look it up?
I considered this reverse-engineering, but arrived at the conclusion
that having a flexible API mattered more to give more flexibility to
module developers. In short this avoids having extra class IDs like
ActivityExtention, TimeoutExtension, etc. But perhaps that's just a
matter of taste..
--
Michael
