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?

christian

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?
>
> christian

It doesn't really make sense to have that, because most (if not all) operating systems only allow rendering from a single thread and I believe OSX (possibly macOS too.) only allows it from the main thread. Which means the only thing you can really operate on other threads are events, but you'll always have to do callbacks to your UI thread in order to render.

On Sunday, 9 July 2017 at 21:12:24 UTC, bauss 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?
>>
>> christian
>
> It doesn't really make sense to have that, because most (if not all) operating systems only allow rendering from a single thread and I believe OSX (possibly macOS too.) only allows it from the main thread. Which means the only thing you can really operate on other threads are events, but you'll always have to do callbacks to your UI thread in order to render.

Aren't all fibers executed from a single thread?

On 09.07.17 23:12, bauss 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?
>>
>> christian
> 
> It doesn't really make sense to have that, because most (if not all) operating systems only allow rendering from a single thread and I believe OSX (possibly macOS too.) only allows it from the main thread. Which means the only thing you can really operate on other threads are events, but you'll always have to do callbacks to your UI thread in order to render.
Thanks for answering! you are touching exactly my question:
Lets say, that all the event handling is done by fiber-aware code (means
all io gives the thread free, when it would block, and perhaps
a yield function for calculation heavy operations). It would then
I think reduce the "risk" of a ANR (Application not responding (from
android) or the famous beachball) without sacrificing the clarity of the
code.

e.g. you want to download something from a webpage and process the data,
if you click a button. you cannot do this in the buttons-onclick
callback (because this is usually a long running operation and the
callback is called from the main thread). with fibers, the main thread
could continue running (and update the screen) as soon as the io thread
is blocking or the process thread calls yield (which he should on a
regular basis). after the processing as soon as the fiber gets back the
control, the result can easily be integrated back into the ui, because
its already in the right thread.
compare this with the traditionally apporach of spawning a new thread,
passing over the arguments, processing it, passing back the result and
integrating this into the ui, it could perhaps be "simpler".

on the other hand, the process code would get a little bit messy because of the manually inserted yields (as far as i know, the erlang vm for example inserts such instructions automatically every n instructions).

what do you think?

On 10.07.17 00:23, Christian Köstlin wrote:
To elaborate on the previous post, I uploaded a small example, that
tries naively to mix dlangui with fibers. Please have a look at:
https://github.com/gizmomogwai/fibered-ui.git
For sure it does not work. The fiber in the callback is started,
but after the first yield, dlangui never returns to the fiber.
Does anybody know what needs to be done for that?

thanks a lot,
Christian

> On 09.07.17 23:12, bauss 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?
>>>
>>> christian
>>
>> It doesn't really make sense to have that, because most (if not all) operating systems only allow rendering from a single thread and I believe OSX (possibly macOS too.) only allows it from the main thread. Which means the only thing you can really operate on other threads are events, but you'll always have to do callbacks to your UI thread in order to render.
> Thanks for answering! you are touching exactly my question:
> Lets say, that all the event handling is done by fiber-aware code (means
> all io gives the thread free, when it would block, and perhaps
> a yield function for calculation heavy operations). It would then
> I think reduce the "risk" of a ANR (Application not responding (from
> android) or the famous beachball) without sacrificing the clarity of the
> code.
> 
> e.g. you want to download something from a webpage and process the data,
> if you click a button. you cannot do this in the buttons-onclick
> callback (because this is usually a long running operation and the
> callback is called from the main thread). with fibers, the main thread
> could continue running (and update the screen) as soon as the io thread
> is blocking or the process thread calls yield (which he should on a
> regular basis). after the processing as soon as the fiber gets back the
> control, the result can easily be integrated back into the ui, because
> its already in the right thread.
> compare this with the traditionally apporach of spawning a new thread,
> passing over the arguments, processing it, passing back the result and
> integrating this into the ui, it could perhaps be "simpler".
> 
> on the other hand, the process code would get a little bit messy because of the manually inserted yields (as far as i know, the erlang vm for example inserts such instructions automatically every n instructions).
> 
> what do you think?
> 

On 2017-07-09 21:43, 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?

If I recall correctly, vibe.d has some form of integration with the native GUI event loop on Windows.

-- 
/Jacob Carlborg

On 2017-07-09 23:12, bauss wrote:

> I believe OSX (possibly macOS too.) only allows it from the main thread.

Yes, that's correct. But what's the difference between OSX and macOS ;)

-- 
/Jacob Carlborg

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.

On 2017-07-10 15:37, Gerald wrote:

> 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.

It's that basically the whole idea of async/await? Seems like Microsoft is pushing quite heavily for that in GUI code.

-- 
/Jacob Carlborg

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.