You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
publicinterfaceIWaitStrategy{ISequenceWaiterGetSequenceWaiter(IEventHandlereventHandler);voidSignalAllWhenBlocking();}// NEW: interface used by sequence barriers to wait for dependent sequencespublicinterfaceISequenceWaiter{SequenceWaitResultWaitFor(longsequence,DependentSequenceGroupdependentSequences,CancellationTokencancellationToken);voidAbort();}// NEW: marker interface for event handler types (IEventHandler<T>, IValueEventHandler<T>, ...)publicinterfaceIEventHandler{}
A similar change would be applied to the IAsyncWaitStrategy interface.
The new design implies that dedicated sequence waiters would be created per event handler, which also implies that sequence barriers would be created per event handler. I do not think it would be an issue. Sequence barriers are already created per event handler for async handlers, and I think that sharing sequence barriers is not required (there have been an open issue for two years in the LMAX Disruptor with this exact question).
The goal of the change is to support creating stateful waiters, which would be valuable for:
adding a clean way to support per handler logic in the wait strategies.
removing allocations in AsyncWaitStrategy by using preallocated IValueTaskSource instances (*).
opening new wait strategy implementation options.
(*): I experimented implementing no-allocation async wait strategies in a branch. It requires adding per handler state in wait strategies. It is possible to pass custom state to the wait strategy in WaitFor, but it is not a clean design (because the wait strategy state is leaking into the sequence barrier), and it is a breaking change of the IAsyncWaitStrategy anyway.
Notes:
It might be possible to indirectly add per handler state in wait strategies by adding a mutable property WaitStrategyState in DependentSequenceGroup. However, it would feel somewhat hacky and would force DependentSequenceGroup to be instanciated per handler.
It might be possible to avoid adding the IEventHandler interface and instead add GetSequenceWaiter overloads for all event handler types.
What do you think?
The text was updated successfully, but these errors were encountered:
I am considering refactoring
IWaitStrategy
. It would be a breaking change, so I am exposing the design here to get feedback before moving forward.Current API:
New API:
A similar change would be applied to the
IAsyncWaitStrategy
interface.The new design implies that dedicated sequence waiters would be created per event handler, which also implies that sequence barriers would be created per event handler. I do not think it would be an issue. Sequence barriers are already created per event handler for async handlers, and I think that sharing sequence barriers is not required (there have been an open issue for two years in the LMAX Disruptor with this exact question).
The goal of the change is to support creating stateful waiters, which would be valuable for:
AsyncWaitStrategy
by using preallocatedIValueTaskSource
instances (*).Notes:
WaitStrategyState
inDependentSequenceGroup
. However, it would feel somewhat hacky and would forceDependentSequenceGroup
to be instanciated per handler.IEventHandler
interface and instead addGetSequenceWaiter
overloads for all event handler types.What do you think?
The text was updated successfully, but these errors were encountered: