Re: glib: processing events in multiple threads
- From: Patrick Ohly <patrick ohly intel com>
- To: Andy Spencer <andy753421 gmail com>
- Cc: gtk-list gnome org
- Subject: Re: glib: processing events in multiple threads
- Date: Tue, 30 Apr 2013 11:30:04 +0200
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]