[vlc-devel] Re: [PATCH] Abnormal memory growing (macosx)

[Derk-Jan Hartman]

Welcome to OS X :D

On 15-dec-2005, at 0:39, jmvallat_vlc at mac.com wrote:
> Don't ask me about the -manage method !  Because... as far as I can  
> see, it's even worse than that: this code is running in a thread,  
> and does call -terminate when the 'intf' dies (by the end of the  
> application).
> The problem is that this -terminate method is also called by the  
> main thread (in function Run())... few nano-second before.
> And if you look at the code of -terminate, you'll see that calling  
> it twice is .. not a good idea.

This stems from the fact that there are multiple ways to "Quit" VLC.
You can call p_vlc->b_die (from any interface), you can choose,  
Applicationmenu->Quit and you can call Dockmenu->Quit.

Unfortunately they all seem to behave different. Especially the Dock  
one is annoying as hell, bacause as far as i can see, you never get a  
report of that. i think that is why multiple terminate methods were  
once added....

Perhaps i should indeed look at this once more.

> This is why VLC.app does often crash when you quit it. (Well, there  
> is perhaps another problem (caused by a memory overrun in src/ 
> playlist/view.c) but I'm not quite yet sure...)).



>
> On 15 déc. 05, at 00:24, Derk-Jan Hartman wrote:
>
>> This doesn't seem like the proper way to solve this issue.
>> Wouldn't it be better to alloc init the date and then release it  
>> after the sleep ?
>>
>> why is there even a Cocoa sleep here anyways, a normal sleep()  
>> should just work fine as well don't you agree ?
>>
>> Come to think of it, the manageVolumeSlider called there shouldn't  
>> be their either. the whole manage: function isn't allowed to do  
>> any GUI work at all.
>>
>> Same for the seScrollField.
>>
>> DJ
>>
>
> --
> This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
> To unsubscribe, please read http://developers.videolan.org/lists.html
>
>

-- 
This is the vlc-devel mailing-list, see http://www.videolan.org/vlc/
To unsubscribe, please read http://developers.videolan.org/lists.html