4 ms·
I recall you have written in favour of structured concurrency before. I'd be interested in your thoughts about how we can combine this with a GUI framework for
by sparkie 2y ago
I recall you have written in favour of structured concurrency before. I'd be interested in your thoughts about how we can combine this with a GUI framework for something better than the status-quo. Most of the other frameworks out there run an event loop in the main thread and just fire-and-forget a new thread when they need to prevent the UI thread from blocking. It's a pretty dire state of affairs.
Try r/programminglanguages, usually get some decent discussions there.
- gavinhoward 2y agoThe 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?