v0.13.0

0.13.0 -- 2024-02-25

Breaking changes

• Bump nix to v0.28. As nix is exposed in the public API, this is a
  breaking change. (#176)

Bugfixes

• Fix a panic that would occur when a task is scheduled in an event callback.
  (#172)

v0.12.4

0.12.4 -- 2024-01-15

Additions

• calloop is now supported for Windows. (#168)
• Add the signals feature to docs.rs. (#166)

Bugfixes

• Fix a borrow error that can occur while using the executor. (#165)

v0.10.0

This release brings a lot of deep changes to calloop, the highlights being:

Error handling is revamped: The error handling machinery of calloop has been completely revamped (thanks to @detly). A calloop::Error type is introduced, and the EventSource trait now has an Error associated type. Each event source now has its own error type.

Timer sources rework: Timer event sources are completely reworked, making them more flexible and integrating them directly into the event loop core logic, thus avoiding to spawn a background thread to manage them. This also introduces a "high-precision mode" for the event loop allowing sub-millisecond accuracy for the timers, it is obtained by initializing it with the try_new_high_precision() method.

Several other changes were introduced in this release:

• The MSRV is bumped to 1.53.0
• The generic::Fd adapter is now removed, as RawFd implements AsRawFd, making Generic<RawFd> usable.
• The internal logic of calloop has been reworked around a slotmap, making the RegistrationToken now Copy. This causes a breaking change to the low-level Poll API.
• The PingSource event source now uses an eventfd instead of a pipe on Linux (thanks to @detly).

Version 0.7.0

This new release of calloop brings two major changes: many 'static requirements were lifted from the API, and calloop now provides adapters to integration with the async/await ecosystem.

Lifetimes relaxation

Thanks to @fengalin in PR #20, EventSource objects and their associated callback are no longer required to be 'static, as long as they outlive the EventLoop. It was necessary to adapt a little calloop's API to make this possible, and as a result this is a breaking change.

The most notable change is that LoopHandle::with_source was removed. If you need to access an EventSource after its insertion into the EventLoop, you now instead need to create a Dispatcher and insert it using LoopHandle::register_dispatcher. The Dispatcher holds both an event source and its associated callback, allows you to mutably access the event source, and can be cloned, allowing you to provide it to the event queue and still keep it.

Async/await integration

With this release calloop now provide two tools for integration with the async/await ecosystem: Futures-aware IO and an future executor.

Future-aware IO is provided by the LoopHandle::adapt_io method, which turns an IO object F into an Async<F> adapter, which provides access to futures that resolve when the object is ready for read or write, as well as implementations of the AsyncRead and AsyncWrite traits from the futures crates if the futures-io cargo feature is enabled. This adapter uses the associated EventLoop to awake the futures when IO is ready, allowing the whole construct to run single-threaded.

The future executor is provided as yet another EventSource implementation behind the executor cargo feature, which introduces the std::futures module containing it. The executor has a T type parameter, and can only run futures that resolve to a value of this type. Every time a future spawned in the executor resolves, its value is forwarded to the callback associated to it in the EventLoop. A generic executor for futures that don't return any value can thus be obtained by taking T = ().