[vlc-devel] commit: Fix memleak (should fix #1081) ( Rémi Duraffort )

Pierre d'Herbemont pdherbemont at free.fr
Mon Aug 25 13:14:33 CEST 2008


On Mon, Aug 25, 2008 at 10:24 AM, Rémi Denis-Courmont <
rdenis at simphalempin.com> wrote:

>
> On Mon, 25 Aug 2008 09:33:21 +0200, Pierre d'Herbemont
> <pdherbemont at free.fr> wrote:
> >> We cannot have reference counting for blocks, because blocks are
> >> modified
> >> downstream. The only thing we have is block_Duplicate, which is of
> >> course
> >> slow: malloc + memcpy.
> >
> > No. The whole point of refcount is when to destroy it. Not to make
> > sure it won't change if you pass it to a function.
>
> Heck no. Reference counting only works if you have a resource that can be
> shared in the first place. For a block of memory the only thing, you will
> at the very least want to share the data - otherwise there is nothing to
> share, so there is no opportunity for reference counting. On top of that,
> there are thread synchronization issues - our block layer is not
> thread-safe at all (let alone the block FIFO).


I meant in that precise case (allow *destroy* ownership not to be passed by
function call). If you want a full thread safe object, that is mutable and
needs copying it's an other problem.

It seems that I am the only one to consider that an ideal API should
preserve *destroy* ownership, unless function name follows an explicit
convention that says it would not. So don't worry :)

Well, we could at least put a comment somewhere to state that... That might
help to prevent dummy error such as this commit.

Pierre.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20080825/e2d2a73f/attachment.html>


More information about the vlc-devel mailing list