www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Fiber based UI-Toolkit

reply =?UTF-8?Q?Christian_K=c3=b6stlin?= <christian.koestlin gmail.com> writes:
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
Jul 09 2017
next sibling parent reply bauss <jj_1337 live.dk> writes:
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.
Jul 09 2017
next sibling parent Meta <jared771 gmail.com> writes:
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?
Jul 09 2017
prev sibling next sibling parent reply =?UTF-8?Q?Christian_K=c3=b6stlin?= <christian.koestlin gmail.com> writes:
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?
Jul 09 2017
parent =?UTF-8?Q?Christian_K=c3=b6stlin?= <christian.koestlin gmail.com> writes:
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?
Jul 09 2017
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jul 10 2017
parent bauss <jj_1337 live.dk> writes:
On Monday, 10 July 2017 at 08:40:15 UTC, Jacob Carlborg wrote:

 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 ;)


Well besides that it's newer versions of the OS, then nothing 
much I guess. It could potentially change such specs though.
Jul 10 2017
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Jul 10 2017
prev sibling parent reply Gerald <gerald.b.nunn gmail.com> writes:
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.
Jul 10 2017
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jul 10 2017
parent reply Gerald <gerald.b.nunn gmail.com> writes:
On Monday, 10 July 2017 at 14:03:59 UTC, Jacob Carlborg wrote:

 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.


Thanks for the link, I'm not active with .Net so I had to go look 
it up. Reminds me a lot of the way node.js works. If all your 
async activity is IO bound maybe it works fine and I'm wrong 
about this.


My past experience has been that it's challenging to determine 
the appropriate times to yield particularly with a lot of async 
activity happening. However with it baked into the framework and 
a simplified API maybe it becomes less of an issue.

I'll have to do more reading on it, again thanks for the pointer.
Jul 10 2017
parent Jacob Carlborg <doob me.com> writes:
On 2017-07-11 04:40, Gerald wrote:


 Thanks for the link, I'm not active with .Net so I had to go look it up. 
 Reminds me a lot of the way node.js works. If all your async activity is 
 IO bound maybe it works fine and I'm wrong about this.
 
 
 My past experience has been that it's challenging to determine the 
 appropriate times to yield particularly with a lot of async activity 
 happening. However with it baked into the framework and a simplified API 
 maybe it becomes less of an issue.
 
 I'll have to do more reading on it, again thanks for the pointer.


I'm not that familiar with .Net either but this async/await feature is 
spreading across languages: C++, JavaScript, .Net, Dart and possibly others.

As far as I understand it consists of two parts: coroutines (resumable 
functions) and asynchronous operations, usually IO. Any async function 
returns some form of future type. If you call that function, it will 
return immediately and let the execution continue. Now it's possible to 
do work that is independent of the result of the previous call. When you 
do need the result of the first call, you call "await" on the return 
value of that call, the future. If the result is ready, everything is 
fine and the execution continues. If the result is not ready, your 
function will suspend and the caller will continue the execution.

You don't need to do any explicit yielding due to the language and 
framework support. The only thing you need to determine is when you need 
the result of an aysnc function call.

-- 
/Jacob Carlborg
Jul 10 2017
prev sibling parent =?UTF-8?Q?Christian_K=c3=b6stlin?= <christian.koestlin gmail.com> writes:
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.
Jul 10 2017