Re: glib: processing events in multiple threads

[richard boaz <ivor boaz gmail com>]

and i do it a different way.  you say you the main loop is not a part of the main processing of your program, but this really doesn't matter.  in this case, you could:

• start a g_main_loop() in a separate thread from the main processing thread, at startup, executing the whole time the program is active
• when any work needs to be done via this loop, use g_idle_add() and friends to execute the necessary function - function will be executed on next main_loop fetch
• you should generally not use g_main_context_iteration(), as you've discovered, you cannot control what happens when multiple things are happening at the same time

this way, since the main loop is running in a separate thread than main(), your synchronous calls that need to execute outside of glib can be invoked from main(), without having to worry about the fact that there is a main_loop() running in a separate thread.

i hurt my brain trying to get my head around your design (no insult intended, really).  only meaning to say, that at a design level, when it has to become so convoluted, this can't be the solution.

richard

On Tue, Apr 30, 2013 at 11:09 AM, Andy Spencer <andy753421 gmail com> wrote:

On 2013-04-30 10:42, Patrick Ohly wrote:
> In SyncEvolution, I am using a library with synchronous method calls
> which is unaware of glib.

> ...

> The real solution would be a g_main_loop_run_if_running() which
> atomically checks the flag and returns immediately if false. Is
> something like that possible with the current API, or are there other
> solutions to the problem?

Hi, I might not understand your situation fully, but in my code I've
generally had a hard time doing anything with the glib main loop
directly and have found it easier to find other ways to do things.

In my case, I'm normally processing some data in a thread using library
calls, then when it finishes I want to display the data to the user. For
me, it's been easier to just save the data at the end of the thread
(ignoring glib for the most part) then call gtk_widget_queue_draw in
some thread-save way and let the main thread pick up the data next time
it gets around to rendering.

You might also want to take a look at GThreadPool's and GAsyncQueue's,
if you haven't done so already. They can sometimes help avoid a few race
conditions.

_______________________________________________
gtk-list mailing list
gtk-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-list