sachanganesh / eventador-rs Goto Github PK

As seen here: https://github.com/sachanganesh/raptor-rs/blob/dc85a593f7a8f8e4ebac04edd32a0e1e3371864f/src/futures/subscriber.rs#L47

The behavior is to loop until the internal state machine determines that the subscriber is able to receive a new event. By using a Waker, the task can be rescheduled when a new event arrives.

Hello! I'm coming to this crate from rust-lang/rust#99389 where we're making the checks stricter for uninitialized data, and this crate fails under those checks, due to the lockfree dependency.

It has already been reported, with no response. Best bet would be to either replace it or fork it.

In the current scenario, all subscribers must walk the entirety of the ring and ignore events that they are not subscribed to. One way to optimize this is to have fast subscribers track the index of the last relevant event they encountered on the ring. When they encounter the next relevant event, the fast subscriber should point the previous event to this one. That way, any slow subscribers can jump from one relevant event to the next, without having to walk through all the irrelevant events in between.

From my understanding, calling block_on inside a poll_x function is a bad practice. However, I'm not sure how else to resolve a call to an async function within a poll_x function.

Currently, there is no way to unsubscribe from receiving an event. In the case that the wait-strategy AllSubscribers is applied, this means that unused subscribers will block publishing of events and deadlock the event-bus. An unsubscribe API would help prevent this.