The way I designed this is actually that the framework starts a thread in which the client runs, using blocking code from the framework. Code would look like t

The way I designed this is actually that the framework starts a thread in which the client runs, using blocking code from the framework. Code would look like this: for (vwt = wy_vwt_create(); event = wy_event(); vwt = wy_vwt_freeze()) { switch (event->type) { // Handle event types... } } That `wy_event()` call is blocking, yes, because it waits for the next event, but that actually doesn't block the UI thread because the client event loop is not on the UI thread. Behind the scenes, the framework would create several threads: one for the client, one for the UI, one for accessibility, etc. The `wy_vwt_freeze()` is the call that would freeze the current VWT, but it would also send notifications to those other threads to do their thing, and they can work separately. This also allows clients to handle events while the next frame is being rendered. So the way to prevent the UI thread from being blocked is to just separate it from the event thread, something VWTs allow by construction. And of course, I would create the threads under structured concurrency, but it's not the key part. Does that make sense?