Skip to content

Introduce non-blocking event queue access #91

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 22, 2023

Conversation

tnull
Copy link
Collaborator

@tnull tnull commented May 11, 2023

So far we only offererd the blocking Node::next_event variant which would block the current thread until an event becomes available. However, non-blocking polling of the event queue is useful, it for example allows to handle events in single-threaded control flow environments.

Here we add a simple non-blocking variant under the same name as previously and rename the previously existing method wait_next_event to highlight its blockiness.

@tnull tnull added this to the 0.1 milestone May 11, 2023
@tnull tnull mentioned this pull request May 11, 2023
47 tasks
So far we only offererd the blocking `Node::next_event` variant which
would block the current thread until an event becomes available.
However, non-blocking polling of the event queue is useful, it for
example allows to handle events in single-threaded control flow
environments.

Here we add a simple non-blocking variant under the same name as
previously and rename the previously existing method `wait_next_event`
to highlight its blockiness.
@tnull tnull force-pushed the 2023-05-add-try-next-event branch from baa8db4 to aa850a3 Compare May 11, 2023 12:17
Copy link

@wpaulino wpaulino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason we don't expose a polling variant instead with the provided runtime?

@tnull
Copy link
Collaborator Author

tnull commented May 21, 2023

Any reason we don't expose a polling variant instead with the provided runtime?

Mh, I'm not quite sure I understand what your asking. There is really no runtime involved in our current event handling as it is blocking (i.e. based on a Condvar), and switching it to async would have no immediate benefit as we'd only expose it blocking (at least for now) anyways?

@wpaulino
Copy link

Basically exposing an alternative to wait_next_event that blocks and polls instead of waiting on the Condvar.

@tnull
Copy link
Collaborator Author

tnull commented May 22, 2023

Basically exposing an alternative to wait_next_event that blocks and polls instead of waiting on the Condvar.

I'm confused: this is what wait_next_event does, just that it also yields and is woken up via the Condvar when a new event is available?

@tnull tnull merged commit 8fd30e8 into lightningdevkit:main May 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants