Clarifications on how the Event Loop works and how to avoid blocking the event loop.

[vikigenius]

I am new to concurrent programming. I read the Calloop book and I am struggling to understand how this enables concurrency.

From the documentation of the run method it seems like it will wait for timeout seconds for a new event. The moment we get a new event it dispatches the associated callback. I have a few questions

1. Will I get no new events when the callback is being executed?
2. What happens if we wait for timeout seconds and there is no new event.
3. Maybe some extreme examples would help. What's the difference between setting timeout to zero vs setting it to None?

Here is a potential scenario:
If I have potentially blocking code in a callback such as reading a huge file, what should I do? Let's say I have an event that indicates that a large file is ready to be read. We will dispatch an associated callback for it. In the callback I want to read the file. But that's a blocking operation now. How would I do this? Will I need to spawn a thread to do this operation so that I can immediately return from the callback? If so it seems like any parallelism/concurrency comes from other code and not calloop itself?

I know this library was written with Smithay in mind. But a full concrete example would be helpful. The ZeroMQ example in the book is good for understanding event sources, but I am still struggling to understand the concurrency aspect. Maybe add to that example with a full main function that also handles some unix signals etc. and some actual processing of the messages: request/response etc.

[elinorbgr]

If so it seems like any parallelism/concurrency comes from other code and not calloop itself?

Calloop only is indeed only concerned by the "concurrency" part, not the "parallelism" part. Its job is to allow you to wait on multiple sources of events and be notified about them efficiently, but contrary to frameworks like tokio or async-std, to does not come with some multithreaded executor (though afaik those are not really friendly to blocking tasks either).

Indeed, if you need to start an operation that is likely to take a long time and do not want to block you whole event loop on it, spawning a background thread is likely to be the correct thing to do. This stuff is by design out of scope for calloop, which is meant to be used in a potentially single-threaded environment.

[vikigenius]

@elinorbgr Thanks for the clarification

I was wondering when would I want to use Calloop over something like:

loop {
    tokio::select! {
        // Select between multiple events here.
    }
}

[elinorbgr]

They have the same basic role, it mostly depends on the context in which you need to use them. Depending on the app you are working on, and it's internal structure and control-flow, calloop may provide an API that is more convenient to use than tokio (that is the case in smithay notably).

[axelkar]

[...] Modelling this processing using futures would force us to constantly rely on Rc/RefCell/Arc/Mutex all over the place.

@elinorbgr I saw your above Reddit comment, and then found out having shared mutable state is in fact possible when using select! {}. Wouldn't it actually be simpler to have select! generating events for users to handle, because so many libraries support async/await? Although I'm thinking from a winit user's perspective.