Fiber based UI-Toolkit

[Christian Köstlin via Digitalmars-d-learn]

On 10.07.17 15:37, Gerald wrote:
> On Sunday, 9 July 2017 at 19:43:14 UTC, Christian Köstlin wrote:
>> I wonder if there is any fiber based / fiber compatible UI-Toolkit out
>> for dlang. The second question is, if it would make sense at all to
>> have such a thing?
> 
> As previously noted, like other UI toolkits GTK maintains a single
> thread for processing UI events with an event loop running in that
> thread. GTK does support passing a function to be called when the main
> loop is idle, it could be possible to leverage this to manage fibers
> with appropriate yielding.
> 
> Having said that, I'm in the camp where this doesn't make much sense.
> Using fibers on the main UI thread is likely going to result in a
> blocked UI whenever a fiber takes too long to do its work. History has
> shown that cooperative multi-tasking typically doesn't work well for UI
> applications.
> 
> I think you would be much better off starting an additional thread and
> managing fibers in that thread outside the context of the main UI
> thread. You can then use things like std.concurrency to receive messages
> from the external thread to update the UI as needed in it's own thread.
Thanks for this answer,

my thinking was also in this direction.
I guess for many use cases fibers in ui could be good enough (like my
simple example, getting something from a webserver, (quickly) process it
and display it). given a fiber-based http-client, this could work quite
nicely. For real programs, with heavy transformation of the data,
I think this would not work so well, because either you block the ui
with the processing code in the fiber, or your processing code is not
running full speed, because it has some yields sprinkled throughout the
code.

On the other hand side, i also guess, that for ui and even more for
audio rendering, every tiny bit of delay can hurt the experience.

So probably not a good idea for a real world application?

Best regards,
Christian

p.s. i still wonder about jacobs argument about microsofts async/await.