On Tue, Apr 30, 2013 at 11:59 AM, Patrick Ohly <patrick.ohly@xxxxxxxxx> wrote:
On Tue, 2013-04-30 at 11:27 +0200, richard boaz wrote:> * start a g_main_loop() in a separate thread from the main
> 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:
> processing thread, at startup, executing the whole time theMy code was not meant to be thread-safe initially. Obviously I now have
> program is active
to change that, either way.
not sure i understand this. i've never heard of wanting or intending something to *not* be thread-safe; that usually only happens when making it thread-safe has not been regarded at the design level. you really *want* your code to be not thread-safe?
> * when any work needs to be done via this loop, use g_idle_add()
> and friends to execute the necessary function - function willHow do you return results of that method call?
> be executed on next main_loop fetch
g_idle_add() takes a pointer. pass a pointer to a structure that can be as complicated as you like it to be to handle the data being passed around. this also is nice in that as the program evolves, the structure's contents can be easily modified, while all the calls passing the pointer around remain the same.
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 whenSo it's broken by design once going multithreaded? I guess I still don't
> multiple things are happening at the same time
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 also find this to be a hole. but i've never been confronted with a situation where an elegant solution couldn't be found without having to rely on it.
I share your concern ;-} I really wish there was a simpler solution.
> 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.
--
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
