im.pidgin.pidgin: d77adf1b9a4b44f121620f20e2643602e3f6776e

[Mark Doliner]

On Mon, 21 Jan 2008 08:46:18 -0500, Evan Schoenberg wrote
> On Jan 21, 2008, at 2:09 AM, Mark Doliner wrote:
> 
> > I disapproved this.  I guess there are two reasons:
> >
> > 1. Checking the validity of a FlapConnection by checking whether the  
> > memory
> > address of the struct exists in a GList is ugly.  I imagine it will  
> > work
> > 99.99999999% of the time, but it is theoretically possible for the  
> > same memory
> > address to be reused for a new and different FlapConnection, which  
> > means you
> > would end up free'ing something you hadn't intended.

*snip*

> Yes, it's ugly.  The same sad-but-necessary technique is used to 
> check  for PurpleConnection objects' validities, for the same 
> reason: If a  callback is registered and is not canceled when the 
> object is freed,  once it is called, we will crash.  
> GObjectification of the objects in  question (with reference 
> counting) -- or implementation of manual  reference counting --
>  would fix the problem.

PURPLE_CONNECTION_IS_VALID is not necessary in correctly written code.  Code
should keep track of the return value from g_timout_add() and use it to cancel
the timer when the object is freed.

GObjectification might make this process a little easier and less manual, but
it is certainly not required.

*snip*

> > For the record I absolutely hate PURPLE_CONNECTION_IS_VALID and  
> > think we
> > should get rid of it.
> 
> Getting rid of it without a replacement would be crashtastic.  I 
> agree  that it's a hack of a solution which only catches those cases 
> we have  the foresight to consider, and I'd love to see it replaced 
> by an  actual solution.  I've held off for a long time now on giving 
> it  reference counting, as each time I return to consider doing so 
> the  GObjectification discussion comes back... and GObjectification 
> would  of course obsolete any such solution.

We don't need a replacement... just keep track of timers and cancel them
appropriately.

-Mark