Implement next_event_async method polling the event queue
#80
Conversation
tnull
force-pushed
the
2024-01-async-event-queue
branch
4 times, most recently
from
40a26e7 to
0bbc34b
Compare
| @@ -65,6 +77,10 @@ impl EventQueue { | |||
| drop(queue); | |||
|
|
|||
| if should_notify { | |||
| if let Some(waker) = self.waker.lock().unwrap().take() { | |||
| waker.wake(); | |||
There was a problem hiding this comment.
this feels a little weird, can you help me understand? is this some weird edge-case where the user is using both the sync wait_next_event and async in tandem somehow / for some reason?
There was a problem hiding this comment.
Yeah, kinda. Users likely shouldn't use both at the same time, but here we just make sure to wake the Waker to poll again if we still have events left to be processed, just as we wake up any parked threads via the Condvar. Tbh. I'm not entirely sure this is necessary, but also shouldn't hurt, IIUC.
I now added a test for the event queue operations that has at least some checks for mixing matching blocking/async APIs.
We implement a way to asynchronously poll the queue for new events, providing an async alternative to `wait_next_event`.
tnull
force-pushed
the
2024-01-async-event-queue
branch
from
0bbc34b to
ad59db9
Compare
tnull
force-pushed
the
2024-01-async-event-queue
branch
from
ad59db9 to
396bdf8
Compare
|
Added a test case for the event queue operations. I'll go ahead and merge this as this only confirms the previously-ACKed code. |
Based on #74.
We implement a way to asynchronously poll the queue for new events,
providing an async alternative to
wait_next_event.