> On Mar 31, 2026, at 15:28, Chao Li <[email protected]> wrote: > > Hi, > > There is an XXX comment in WalSndWait(): > ``` > * XXX: A desirable future improvement would be to add support for CVs > * into WaitEventSetWait(). > ``` > > I have been exploring a possible approach for that. This patch is a PoC that > adds ConditionVariable support to WaitEventSet. This v1 is mainly intended to > gather feedback on the design, so I have only done some basic testing so far, > such as a normal logical replication workflow. > > I’d like to highlight a few key points about the design: > > 1. In the current WalSndWait(), although it prepares to sleep on a > ConditionVariable, it does not actually check whether the CV has been > signaled. In this PoC, I kept that same behavior. However, I tried to make > the WaitEventSet support for CVs generic, so that if we want to add actual > signal checking in the future, that would be possible. > > 2. To keep the design generic, this patch introduces a new wait event type, > WL_CONDITION_VARIABLE. A WL_CONDITION_VARIABLE event occupies a position in > the event array, similar to latch and socket events. When a CV is signaled, > the corresponding WL_CONDITION_VARIABLE event is returned in occurred_events. > > 3. The WaitEventSet APIs AddWaitEventToSet() and ModifyWaitEvent() are > extended to support CVs by adding one more parameter “cv" to both APIs. The > downside of this approach is that all call sites of these two APIs need to be > updated. I also considered adding separate APIs for CVs, such as > AddWaitEventToSetForCV() and ModifyWaitEventForCV(), since CVs do not rely on > the kernel and it might therefore make sense to decouple them from socket and > latch handling. But for v1, I chose the more generic approach. I’d be > interested in hearing comments on this part of the design. > > 4. One important point is that this patch extends the WaitEventSet > abstraction, not the underlying kernel wait primitives. A ConditionVariable > is still a userspace/shared-memory concept, but with this design it can > participate in the same waiting framework as sockets and latches. I think > that is useful because it allows mixed waits to be handled through one > interface. > > Here is the v1 patch. > > Best regards, > -- > Chao Li (Evan) > HighGo Software Co., Ltd. > https://www.highgo.com/ > > > > > <v1-0001-Add-condition-variable-support-to-WaitEventSetWai.patch>
I just noticed that I missed checking in my last edit when switching to the other branch, so attaching an updated v1. Best regards, -- Chao Li (Evan) HighGo Software Co., Ltd. https://www.highgo.com/
v1-0001-Add-condition-variable-support-to-WaitEventSetWai.patch
Description: Binary data
