Re: glib: processing events in multiple threads

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

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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]