[compiz] [PATCH] Remove timeout callback

[Mike Dransfield]

David Reveman wrote:
> On Mon, 2007-04-23 at 16:14 +0100, Mike Dransfield wrote:
>   
>> David Reveman wrote:
>>     
>>> On Mon, 2007-04-23 at 14:28 +0100, Mike Dransfield wrote:
>>>   
>>>       
>>>> While working on the python plugin, I realised that the
>>>> timeout system does not allow for notification when a timeout
>>>> is removed.  This has been fine up until now because he closures
>>>> never needed to be cleaned up.
>>>>
>>>> In the python plugin, I pass through a custom structure which
>>>> needs to be cleaned up if the timeout is removed.  This is almost
>>>> certainly the cause of some horrible memory leaks for me.
>>>>
>>>> The attached patch is a simple solution to the problem.  I think
>>>> it should be good enough for most situations.
>>>>
>>>> I could maintain some sort of lookup inside my plugin, but I think
>>>> other plugins would benefit from this.
>>>>
>>>> It is OK to go in or were there any comments?
>>>>     
>>>>         
>>> Timeouts are only removed as a result of the timeout call-back function
>>> returning FALSE. So unless I'm missing something, all cleanup can be
>>> done in the regular call-back function before returning FALSE.
>>>
>>>   
>>>       
>> The pyplane (and the original plane) use a timeout which gets
>> canceled if the user quickly switches back to another viewport.
>> It is not a problem for plane because the closure is a CompScreen
>> which does not need to be cleaned up.
>>
>> The plugins call compRemoveTimeout to stop it.  I'm not sure if this
>> is right in this case, but it seems that it would be useful to stop a
>> timeout before it expires, and it makes it easy to clean up the closure
>> without having to maintain a lookup table of handles to closures.
>>     
>
> OK, I see. 
>
> 1. compRemoveTimeout can return the closure pointer.
>
> 2. We add a function like this:
>
> void *
> compTimeoutGetUserData (CompTimeoutHandle handle);
>
> 3. We add a remove call-back function (your patch).
>
>
> I'm in favor of solution 1, it's simple and efficient. What do you
> think?
>   

Yes, number 1 sounds like a better solution.

Ill prepare some patches for that.  Should I also increase the
ABIVERSION when I do this?

> - David
>
>