Re: Threads and idle functions

[James Morris <jwm art net gmail com>]

On 3 July 2012 02:10, James Morris <jwm art net gmail com> wrote:
> (sorry forgot list)
> On 3 July 2012 01:50, David Buchan <pdbuchan yahoo com> wrote:
> > My understanding is that child threads must never alter the UI in any way.
> >
> > If I have a program which spawns a child thread to download some data and I want to be able to have a 
> > dialog pop up should an error occur, is it correct to say that I need an idle function to be running 
> > concurrently to monitor some global variable which would contain the status (set by the download thread), 
> > and then the idle function would create the dialog pop-up?
> >
> > Put another way, if only the GTK+ main iteration is allowed to alter the GUI, then how does someone get 
> > information out of a child thread and to the UI?
>
> Well from what I hear, g_idle_add offers some form of thread safety so
> a child thread can communicate some item of data via a callback
> executed in the GUI thread.
>
> The documentation also seems to support this view:
> http://developer.gnome.org/glib/2.31/glib-The-Main-Event-Loop.html#glib-The-Main-Event-Loop.description

Forgive me if I speak as if the thread safety of g_idle_add is
something to be doubted. Multi-threaded applications are typically
complicated affairs and the ease of use of g_idle_add rather contrasts
with my (non-professional) experience. That being said, there are
probably limits to what can be accomplished using it but for basic
use-cases such as these it is perfect.


> your child/download thread does the monitoring of the error status and
> when an error is found, use g_idle_add to wait some moments and then
> communicate the error to a callback.
>
> HTH,
> James.