Fiber based UI-Toolkit
Christian Köstlin via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Sun Jul 9 15:23:36 PDT 2017
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?
More information about the Digitalmars-d-learn
mailing list