Re: glib: processing events in multiple threads

[Patrick Ohly <patrick ohly intel com>]

On Tue, 2013-04-30 at 12:12 +0200, richard boaz wrote:


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

I've heard from quite a few people in particular in the GNOME camp who
believe that everything should be asynchronous and that multithreading
is evil. While I am more pragmatic about it, I was following that
approach as long as I could in this case.

To be more specific: what I wanted to avoid was the need to protect data
with mutices by ensuring that the only code ever touching it is from the
same thread. That is easier to enforce than correct mutex locking.

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

Okay, combine with GAsyncQueue for returning the data to the originating
thread and I see how that'll work. That covers a method call which is to
be executed in the event thread plus result. More work will be necessary
for handling asynchronous calls called by the worker which then report
completion in the main thread, but also that looks doable.

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