Comment 19 for bug 1112195

Ah, I think I get it now. So, the client essentially runs async invocations along the lines of read_from_keyboard(), wait_for_touch_event(), and so on and then synchronously reacts to whichever happens first instead of having a callback invoked?

I guess that justifies something like wait_for() where I can wait for any one of a number of outstanding calls to complete.

I would probably still prefer a thread pool inside Mir that would be responsible for invoking callbacks but, not knowing anything about the internals of Mir, that may well be inappropriate. (There is also the issue of thread affinity, for example, for GL rendering where the same thread has to make all the rendering calls.) We did solve this particular issue in Ice, where there were similar concerns; the solution was to allow the application to define whether it wanted to service incoming requests (similar to completion callbacks) from a common thread pool, or whether specific kinds of requests were to be served from a separate pool. By setting the pool size to 1, you got single-threaded operation, with the same thread making the callback each time, and without losing concurrency with other incoming requests.

Pool creation and the like was hidden from the application. All the application had to to is create a receiver object and (as a run-time configuration item) set a thread pool size for each receiver object; the Ice run time did the rest.

Anyway, I'll shut up now. I don't know enough about Mir's internal design and requirements to know whether such a design would be appropriate :-)