Threading to prevent GUI Freeze

Gerald via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Mon Jan 4 09:33:28 PST 2016


On Monday, 4 January 2016 at 16:13:50 UTC, TheDGuy wrote:
> Thanks for your example code. Do i need those extern (C) 
> function?

Yes, you need it. The extern (C) function is what GDK invokes on 
idle. In any GUI application there is a lot of idle time waiting 
for events, what the addThreadIdle allows you to do is take 
advantage of this and tell GTK that whenever it's sitting around 
doing nothing, give this function a call.

The idea is that you spawn a thread that does your work and when 
GTK invokes your thread idle callback where you can check the 
status of the thread and update the UI accordingly. For example, 
let's say you need to render a highly complicated graph that 
takes a few minutes to complete. You could spawn a thread that 
renders it into an off-line buffer of some sort and once 
completed sends a message to the GTK main thread using 
std.concurrency. At some point GTK calls your thread idle 
callback and you simply invoke the std.concurrency.receive and 
see a message saying the graph has been rendered is available, 
and if so, copy it into the appropriate GTK widget.

The important thing to understand is that the thread idle 
callback happens in the GTK main thread so it is completely safe 
to update GTK widgets from here. The other thing to understand is 
that whatever you work you do in the callback must be short, if 
you don't return in a reasonable amount of time you are blocking 
the main GTK thread. As a result it really should only be used as 
a mechanism to track work progress in whatever threads you have 
spawned.

The GTK thread idle callback works beautifully with D's 
std.concurrency send and receive mechanism.

Note the code I pointed you to in that D github Issue abstracts 
the extern (C) function from you and allows you to use normal D 
delegates as callbacks. The issue was created to get this 
incorporated into GtkD as I agree the framework should abstract 
this.

> Why is it not possible to write the value to the TreeView in D?

I don't understand what you mean as of course it's possible to 
update value's in a TreeView. Do you mean why am I updating it 
from the callback (i.e. the C function)? The code here is an 
artificial example where it is simply updating the treeview with 
an iterating number generated in a separate thread. The results 
being posted to the TreeView could just as easily be a resultset 
from a long running database query, a complicated mathematical 
expression, etc. Hopefully the previous explanation helps you 
understand what the callback is doing.

You can see a more real world example of GtkD multi-threading in 
this application I wrote called Visual Grep 
(https://github.com/gnunn1/vgrep), it puts a GTK GUI around grep 
with all searches running in background threads and updating Gtk 
TreeView as results come in. It also uses the delegate code 
linked in that issue which originally came from an application 
called grestful.

Note Visual Grep was my first ever D/GtkD program so there is 
some ugh code in there, but hopefully it can act as an additional 
source of info for you.




More information about the Digitalmars-d-learn mailing list