AsyncEventQueue (AsyncEventBus replacement).

[cheatfate]

Because its impossible to achieve goals which was initially set for AsyncEventBus. So this new structure will become as replacement for AsyncEventBus.

[arnetheduck]

So, as I see it, the principal difference between AsyncEventBus and AsyncEventQueue is that the former gets a single piece of data to users whereas the latter gets many.

Both are useful - ie it's often the case that one wants to notify some listeners about a change, but only the latest version of the change is interesting (ie a counter that changed and has to be displayed on a screen - if it changed many times before it's displayed, the latest value should be "read" in the event - is that the current semantic of AsyncEventBus? If yes, I'd think we should keep both primitives rather than this being a replacement.

In terms of this queue, we'll need the option to set bounds on it so that we can deal with slow subscribers (by kicking them out, more or less).

[arnetheduck]

shouldn't this be a cancel?

[cheatfate]

Why? to raise CancelledError from closeWait() procedure?
The idea here is to ensure that all event consumers will receive notification about that AsyncEventQueue is get closed, and because all this callbacks get schedule inside ab.close() call, it means that continuation procedure will be scheduled after all the consumer notification callbacks will be already processed.

[arnetheduck]

all this offset stuff is to avoid copying the list of readers?

[cheatfate]

Nope, offset indicates from which point in the queue you should start reading events.

[cheatfate]

AsyncEventBus is not flowed only when producer emits event with emitWait(). But this means that in our use-case processing queue could be blocked until consumer will not receive event with waitEvent().

AsyncEventBus issue happens when producer emits events with emit(). Inside emit() consumers list is notified with first event and this consumers list is got emptied. So until consumer will not be scheduled all calls to emit() just discarding events...

So as AsyncEventBus it does not provide the core functionality, and its why it should be deprecated/removed.

[cheatfate]

Because every consumer has its own offset field, which tracks its position in the shared queue, its unlikely to be happened in such case. But on other side there could be very slow event's emitter.