What happens when the callback blocks?

[kangalio]

Hi, you've said that the callbacks passed to MiniInput::connect "will never be called concurrently with itself". Now I'm wondering; what happens when the callback takes, say, two seconds to complete? What happens with midi messages arriving in those 2 seconds?

Those midi messages can't be processed right away because the callback is busy, so I could imagine several things:

• they get discarded
• they get queued, and will be processed when the callback finishes
  • how long is the queue? What's the limit where messages will start to get dropped?
• or something else entirely (panic?)

[Boddlnagg]

It's an excellent question what happens when the callback blocks!

In general it's a very bad idea to block in the callback, but I've never tried it, and it probably depends on the backend. Maybe you can just try what happens when you thread::sleep in the callback? (I will do it myself when I have time.)

We should definitely document that blocking is forbidden in the callback. But we should also make sure that there is no safety issue from violating the assumption that the callback is not called concurrently with itself (maybe that can actually happen? I don't know ...).

[kangalio]

Alright, I experimented, and found the following:

On my configuration - Linux, ALSA - if the callback blocks, pending messages will get queued. Apart from the one message in processing, only up to 100 messages fit into that queue. If 101 or more messages arrive while the callback is blocking, all pending messages will be discarded, and midir will print "Error in handle_input: no input event from ALSA MIDI input buffer!" to stderr.

Tl;dr: up to 100 pending messages will get queued; anything beyond that and all messages will get discarded. In no case will midir panic.