On Tue, 2013-04-30 at 11:27 +0200, richard boaz wrote: > 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 My code was not meant to be thread-safe initially. Obviously I now have to change that, either way. > * 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 How do you return results of that method call? I have seen this suggestion before and the same question was asked then, without a good answer (or at least none that I have found). > * 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 So it's broken by design once going multithreaded? I guess I still don't understand why gmain.c goes to all the trouble of supporting ownership of a context in different threads when that support can't be used reliably. > 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. I share your concern ;-} I really wish there was a simpler solution. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list