Re: Race condition during Dispatcher deconstruction

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

On Jan 8, 2008 2:53 PM, Chris Vine <chris cvine freeserve co uk> wrote:
> I think we did and I think your conclusion was the same; it's a matter
> of trade-offs.  Adding a comment to the documentation that the user is
> responsible for ensuring a particular Glib::Dispatcher object remains
> valid until the last signal emitted on it has been handled, as I think
> you propose, would be one way of dealing with it.  (In case I
> misunderstood your proposal, it is not a matter of keeping at least one
> Glib::Dispatcher alive, it is a matter of keeping the particular
> Glib::Dispatcher object which has been invoked alive until its event has
> been handled by the receiving thread to prevent emitting on a
> non-existent signal object in
> Glib::DispatchNotifier::pipe_io_handler().)

Okay, just to be the Devil's Advocate here: tracking whether the
signal handler has been run corresponding to the most recent emit()
call seems inherently racy to me. How does one make certain that the
handler you're running at this moment is really the last one? I can't
think of any unique token handed back by emit() that would let you
know this.

I suppose if you have a fixed cardinality of X many signal handlers
for every one dispatcher, you can just examine to make sure that that
ratio has been reached before allowing the UI thread to delete the
Dispatcher. I'm open to more elegant solutions, though. :)