Re: glib: processing events in multiple threads

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
        > matter.  in this case, you could:
        >       * start a g_main_loop() in a separate thread from the
        >         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
        >         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.

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