Re: glib: processing events in multiple threads



On Tue, 30 Apr 2013 11:06:38 -0400
"Jasper St. Pierre" <jstpierre mecheye net> wrote:
On Tue, Apr 30, 2013 at 10:58 AM, Chris Vine
<chris cvine freeserve co uk>wrote:
On Tue, 30 Apr 2013 10:44:43 -0400
"Jasper St. Pierre" <jstpierre mecheye net> wrote:
On Tue, Apr 30, 2013 at 10:40 AM, Chris Vine
<chris cvine freeserve co uk>wrote:
[snip]
In this example, the worker thread is sending stuff back to the
main program thread's main loop.  It presumes that the main
program thread has passed the work to the worker beforehand in
an appropriate way. That could be by starting a new thread for
it, by pushing it onto a thread pool, or by giving the worker
thread its own main loop and pushing work to it with an idle
source (you can't use g_idle_add() or g_idle_add_full() for
that because those functions do not enable you to choose your
GMainContext, but it is trivial to write you own function to do
this in order to hand work to any thread's main loop).
[snip]
Has anybody looked into GTask? It's a simple way to make a worker
thread for some heavy processing, give it some data, and be
notified on its completion or failure.

It's the recommended way to run a synchronous task in another
thread in the GNOME world.

That is well mentioned.  It has a nice implementation if you are
stuck with C, provided you have glib-2.36 available.  So far, I
think the only stable distribution with that version is ubuntu
raring.  Possibly arch may just have acquired it.

Note that GTask replaced GSimpleAsyncResult, which has a considerably
lousier API, but is still workable for doing the same thing. If you
need more availability, you should use that.

And with a hideous API as you say.  If using C and in the absence of
GTask (or in the event of GTask being suitable for the job in hand) I
would use one of the other three methods mentioned.

Chris


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]