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
Waiting on a file descriptor to become readable is an increasingly common way on linux systems to tie together C-libraries that are async in one way or another. Examples are libwayland-client and libpipewire, but there are others as well. It is just better in every way than having to spawn a separate thread to run those (these libraries also provide fully blocking functions that interact with the fds). This used to integrate super well with the crystal event loop by making use of wait_readable : example: https://github.com/yxhuvud/wayland_client/blob/main/src/display.cr#L50.
However, in crystal 1.15 wait_readable (and the less useful wait_writable) was removed as part of the other event loop work. It would be nice to have them back, or to have some other way to achieve the same end result, as it allows clean integration with these libraries even in single threaded mode. I'd be totally fine in having them back documented as unstable and subject to change while waiting for a more long-term solution.
These methods are not implementable on Windows (especially not wait_writable - wait_readable might be by resorting to private functions). That is a problem, but the use case is to do bindings with libraries that are not multi-platform anyhow, so it shouldn't be a blocker as this is functionality that really can't be implemented by thirdparty libraries in an easy way without resorting to monkey-patching stdlib.
The text was updated successfully, but these errors were encountered:
Just FTR because it's not 100% clear from the OP: wait_readable and wait_writable have always been internal APIs and were not indended for direct use from user code.
I do understand the use case though and agree that we should offer a solution, ideall with a public, supported API ;)
Perhaps a simple replacement would be to make the respective methods in Crystal::EventLoop::Polling visible?
For a proper API, I'm wondering if we could use a zero-size read (or write) operation.
Apparently this mechanism works with IOCP as well and that's how this could be implemented on Windows (at least for sockets; not sure about other file descriptors).
Feature Request
Waiting on a file descriptor to become readable is an increasingly common way on linux systems to tie together C-libraries that are async in one way or another. Examples are libwayland-client and libpipewire, but there are others as well. It is just better in every way than having to spawn a separate thread to run those (these libraries also provide fully blocking functions that interact with the fds). This used to integrate super well with the crystal event loop by making use of
wait_readable
: example: https://github.com/yxhuvud/wayland_client/blob/main/src/display.cr#L50.However, in crystal 1.15
wait_readable
(and the less usefulwait_writable
) was removed as part of the other event loop work. It would be nice to have them back, or to have some other way to achieve the same end result, as it allows clean integration with these libraries even in single threaded mode. I'd be totally fine in having them back documented as unstable and subject to change while waiting for a more long-term solution.These methods are not implementable on Windows (especially not wait_writable - wait_readable might be by resorting to private functions). That is a problem, but the use case is to do bindings with libraries that are not multi-platform anyhow, so it shouldn't be a blocker as this is functionality that really can't be implemented by thirdparty libraries in an easy way without resorting to monkey-patching stdlib.
The text was updated successfully, but these errors were encountered: