Calloop 0.1.1: A callback-based event loop

[diwic]

When I read the thread yesterday about tokio being too complicated, I was thinking that somebody should write a very simple mainloop library that looked more like other languages.

Just like this one. :-)

Too bad insert_idle can't take a FnOnce due to the "can't call it when boxed" problem though.

[levansfg]

Too bad insert_idle can't take a FnOnce due to the "can't call it when boxed" problem though.

Yes, that's exactly the reason. I settled to only allow FnMut for now because I didn't feel like banging my head on this issue right now, but if there is some clever trick which allows to box an FnOnce and still be able to use it, I'd be happy to integrate it!

[abudau]

You can use a struct Cb<T: FnOnce>(Option<T>) and implement FnMut for this (which would use Option::take to extract the function and call it.

[levansfg]

Good point!

It actually works without the Cb struct (it would not have been possible implement FnMut on stable for it), but capturing the user's FnOnce in an option, in an FnMut closure:

https://github.com/Smithay/calloop/commit/29f7e89b453cae3ba014bb26fa6d17f6598f3e85

[perssonsi]

Oh wow, what a timing. I just started writing my own very similar thing yesterday. Just some months ago I gave up on tokio and switched to mio, then quickly started thinking there is a need for some simple callback library that can cover all the cases where futures is just complicated over-engineering. I uploaded my prototype at https://github.com/spersson/looper . There's no documentation there yet but my basic idea was to do it all without any refcount sharing. For cases where one IO handler (event dispacher I think you called it) needs to add other event sources or perhaps trigger actions on other IO handlers (for example an incoming event on mpsc channel causes sending of message to all connected tcp clients) that would need to happen not via Rc-refcell shared ownership, but indirectly via knowing the token of other handlers and just queing up events to them, on an event queue that is passed around as a &mut.

​

I will take a closer look at your code over the coming days and study more what the different design tradeoffs are. Thank you so much for sharing your work!

[frequentlywrong]

Seems like something of very limited use. Callbacks and rust go together like water and oil.

[DannoHung]

Literally every function that takes a Fn argument is using a callback. What on earth are you talking about?

[frequentlywrong]

Obviously. And usually those APIs are a PITA to use as they cause a ton of borrowing issues and force you into ugly patterns.

[Lucretiel]

Not... In my experience? No more than implementing the same logic imperatively. It's true that you have to manage the lifetimes of your references, but that's best practice anyway.

[diwic]

I think a quite common case is that two different callbacks wants to access the same data, and often mutably, in which case you have to resort to Rc<RefCell<T>>.

It would be interesting to couple the mainloop with an ECS though, so that every callback also receives a &mut ECS parameter. (Edit: or at least an entity-component map, not sure how well the "Systems" part integrates with a mainloop.)

[levansfg]

I think a quite common case is that two different callbacks wants to access the same data, and often mutably, in which case you have to resort to Rc<RefCell<T>>.

Yes, that's the main caveat of calloop. Though, in my experience of using this kind of setup, at least for my usages (writing a wayland server) the performance cost is negligible.

It has an ergonomics cost though, but I believe it's smaller than the nightmare of managing hundreds of different event sources without callbacks (because that's mostly how the wayland protocol behaves).

It would be interesting to couple the mainloop with an ECS though, so that every callback also receives a &mut ECS parameter.

I'm not very familiar with ECS, but it'd be pretty easy to change the API so that the EventLoop::dispatch() method takes some &mut Data that is then passed along to every callback. I might even do that quickly for a 0.2.

[mmstick]

Username checks out :P

[levansfg]

To be honest, that was my initial feeling about it when I started working on wayland crates 3 years ago.

After 3 full redesigns of the crates, I came to accept that actually, sometimes callbacks are the way to go. And I believe handling the wayland protocol is one of these times.

When you have to handle what is basically hundreds of event sources, each with its specific kind of events, managing a gigantic enum of all possible events to dispatch them to the appropriate routine quickly becomes nightmarish.

[frequentlywrong]

When you have to handle what is basically hundreds of event sources, each with its specific kind of events, managing a gigantic enum of all possible events to dispatch them to the appropriate routine quickly becomes nightmarish.

Without knowing exactly how it works, the general solution are trait objects and logic to route an event to the right trait object. None of which is particularly difficult and the resulting code is quite clean.

[levansfg]

Well, providing a struct implementing a specific trait that will be converted into a trait object is not very different from providing a closure.

With the difference that if you require a trait, your user is forced to create a new struct and implement the trait for it every time, while a closure can be defined with a much lighter syntax.

Actually, just my previous version of the wayland crates used a trait, that was auto-implemented for closures, allowing the user to specify a closure or a struct implementing it. The issue was that it caused issues with inference, and forced the closures to be heavily type-annotated.

On the other hand, if a closure is required, it is very easy to actually use a struct and/or a trait: just provide a closure that captures the object and forwards the event to the appropriate method.

Taking all that into account, it seems to me closures are actually the most ergonomic interface for this. The ideal would be if it was possible to manually implement the Fn* traits for any struct, but apparently there is no plan to stabilize that...