Re: glib: processing events in multiple threads

[Patrick Ohly <patrick ohly intel com>]

On Tue, 2013-04-30 at 09:09 +0000, Andy Spencer wrote:
> On 2013-04-30 10:42, Patrick Ohly wrote:
> > In SyncEvolution, I am using a library with synchronous method calls
> > which is unaware of glib.
> > ...
> > The real solution would be a g_main_loop_run_if_running() which
> > atomically checks the flag and returns immediately if false. Is
> > something like that possible with the current API, or are there other
> > solutions to the problem?
>
> Hi, I might not understand your situation fully, but in my code I've
> generally had a hard time doing anything with the glib main loop
> directly and have found it easier to find other ways to do things.
>
> In my case, I'm normally processing some data in a thread using library
> calls, then when it finishes I want to display the data to the user.

That implies going fully multithreaded, including explicit passing of
information back and forth between threads. I was hoping to avoid that.

> You might also want to take a look at GThreadPool's and GAsyncQueue's,
> if you haven't done so already. They can sometimes help avoid a few race
> conditions.

I'm aware of these classes. I found GThreadPool very hard to use
correctly. For example, when I allocate a struct and pass it to
g_thread_pool_push(), what do I do if the method returns false?
Sometimes I have to delete the struct, sometimes not, and it is close to
impossible to tell reliably from the returned information. But let's not
get sidetracked...

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