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 <andy753...@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 > >
_______________________________________________ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
