[vlc-devel] Re: vlc: svn commit r20620 (pdherbemont)

[Damien Fouilleul]

Pierre d'Herbemont wrote:
> Selon Damien Fouilleul <damien.fouilleul at laposte.net>:
>
>   
>> Subversion daemon wrote:
>>     
>>> r20620 | pdherbemont | 2007-06-18 21:58:16 +0200 (Mon, 18 Jun 2007) | 2
>>>       
>> lines
>>     
>>> Changed paths:
>>>    M /trunk/mozilla/control/npolibvlc.cpp
>>>
>>> Mozilla: Attempt to match libvlc input to media_instance changes.
>>>
>>>  > http://trac.videolan.org/vlc/changeset/20620
>>>
>>>
>>>       
>> hmm, i don't like 'libvlc_media_instance_destroy_and_detach' name and
>> what it does, it's actually not what libvlc_input _free() did, as the
>> latter only freeed the memory related to the libvlc_input object, not
>> the input object itself.
>>     
>
> Well that is exactly the difference between libvlc_media_instance_destroy and
> libvlc_media_instance_destroy_and_detach.
>
> libvlc_media_instance_destroy_and_detach did exactly what libvlc_input_free did,
> plus destroying it's own media_descriptor. It doesn't release the
> input_thread_t...
>
> However I certainly agree with the fact that the name is not good at all, I did
> that when I discovered that the mediacontrol API did use that trick... Without
> much thinking.
>
>   
>> Could you also use proper OO semantics as well,
>> libvlc_media_instance_destroy_and_detach means absolutely nothing to the
>> 'casual' programmer; try pairing 'get' calls with a matching 'release',
>> as most OO language do. you could also use reference counting,i.e:
>>     
>
> We currently use the _new constructor plus the _destroy destructor (that's
> libvlc historic keyword) and I gladly take your suggestion about having a:
>
> libvlc_media_instance_release()
>
> that destroy the media_instance object but not it's associated vlc's
> input_thread_t.
>   
the problem is that most of VLC internal objects already uses 
refcouting, and not using this in libvlc either directly or indirectly 
will cause trouble (and it is already causing with the old/current libvlc)

For example, when i ask to GET the playlist input object through libvlc, 
i'm given a libvlc_input_t object, which contains a pointer to the 
actual input_t object, unfortunately nothing stops the playlist code 
from destroying the actual input_t object from under me (basically on a 
STOP request, or end of playlsit, whatever), leaving me with a useless 
libvlc_input_t object, which will probably cause a crash the next time i 
use it. Using refcounting should solve it, you could always increase the 
input_t refcounting on a libvlc GET and decrease it on a RELEASE, 
possibly even adding a RETAIN method as well

> But I am really not fond of the idea to add the extra OO refcount overhead,
> Objective-C and other OO languages already do that fine for us... Let's keep the
> code simple and don't add more than needed.
>
>   
this is true, but you still need to provide a consistent and reliable 
API for those language to use
> Thanks for your suggestions and comments!
>
> Pierre.
>
>   

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