Re: Race condition during Dispatcher deconstruction

["Matt Hoosier" <matt hoosier gmail com>]

On Jan 7, 2008 1:07 AM, Daniel Elstner <daniel kitta googlemail com> wrote:
> Hm, this is a bit confusing to me. What do you mean by "allowing" and
> "reclaiming" the Dispatcher?

Oh, sorry. That was a typo. I meant "allocating" and "reclaiming".
I.e., constructor and destructor.

>
> > Specifically, I get a crash in the Dispatcher::pipe_io_handler
> > function during a GIOSource [presumably, the one registered by the
> > receiver side of the Dispatcher] callback execution.
> >
> > Does this sound plausible? If so, is there a known safe pattern to
> > avoid this race?
>
> If the Dispatcher is created and destroyed together with the widget
> which registers the callback, then you did indeed hit the scenario
> already described by Chris Vine.

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.

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.

--Matt