Re: Race condition during Dispatcher deconstruction

[Daniel Elstner <daniel kitta googlemail com>]

Hi,

Am Montag, den 07.01.2008, 08:43 -0600 schrieb Matt Hoosier:

> Well, the application already does this. It seems like joining on the
> background thread has no effect here, because the "damage" is that the
> byte is already written to the pipe before the background thread
> exits. Then there's the Glib::signal_io() handler sitting out there
> waiting to fire on the UI thread's side of things, possibly after the
> Dispatcher has already been destructed.

Well, you would have to join *before* destroying the Dispatcher. Judging
from your description, I guess this is not possible in your case? You
said it's an a library -- maybe you could just fix the library directly?
(I think it counts as a library bug; definitely so if there is no
workaround).

> I know that the DispatcherNotifier object attempts to avoid this by doing
> 
>   conn_io_handler_.disconnect()
> 
> in its own destructor, but the crash inside pipe_io_handler() after
> I'm certain that the destructor for the Dispatcher has run, makes me
> wonder if this isn't really disconnecting the GIOChannel underneath.

When I came up with the Glib::Dispatcher implementation I simply didn't
think of this scenario; i.e. the internal DispatchNotifier object was
never designed to live on beyond the life cycle of the last Dispatcher
instance.

Hm, I thought this was mentioned in the documentation but it appears it
isn't stated directly, although it could probably be inferred. The life
cycle of a Dispatcher is entirely the business of the receiving thread.
The documentation already states that bar additional locking, the
Dispatcher has to be instantiated before creating the sender thread. I'm
going to add the missing information about the destruction of the
Dispatcher.

--Daniel