Re: glib: processing events in multiple threads

[richard boaz <ivor boaz gmail com>]

On Tue, Apr 30, 2013 at 11:59 AM, Patrick Ohly <patrick ohly intel com> wrote:

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.

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 will
>         be executed on next main_loop fetch

How do you return results of that method call?

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 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 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 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.