Re: glib: processing events in multiple threads

[Patrick Ohly <patrick ohly intel com>]

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.