Re: Is g_source_remove threadsafe?

On Fri, 16 Nov 2007, Alexander Larsson wrote:

On Fri, 2007-11-16 at 14:04 +0100, Tim Janik wrote:
On Fri, 16 Nov 2007, Alexander Larsson wrote:

I'm doing something where i have one thread queueing idles and timeouts
in a thread, and the main loop consumes this. In some cases i want to
remove the sources (to replace a timeout with an idle). However:

Am I missing something obvious here?

simply use g_source_remove (id) instead.

Eh, thats the call I talked about.

sorry, i mistook the call to g_source_destroy(GSource*) for your own code, and
thought you'd wrongly try to use g_source_destroy() instead
of g_source_remove(guint).

yes, you're right, there's a race in the implementation of g_source_remove()
and also g_source_remove_by_user_data, g_source_remove_by_funcs_user_data.
this must have been introdcued when we moved away from hook lists, for
which removal by id was safe.

the code here needs fixing to either move the searching into internal functions
so a single lock can be held around searching and destroying the sources, or
by just making g_source_remove() thread safe again via inlining of
find_source_by_id, and then provide alternative APIs to search for source *ids*
instead of pointers from user_data and funcs.
changing the API for source searching is actually needed anyway to get rid of
the thread race inherent in the current API (g_main_context_find_source*()
return GSource pointers but no lock is held when they return and they don't add
a reference count to the sources. so the pointer may already be invalid when
the functions return).


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