[MPlayer-dev-eng] [PATCH] vo_macosx.m - test proxy messages

[Ulion]

2007/11/25, Chris Welton <electrostatic_1 at yahoo.com>:
>
> --- Ulion <ulion2002 at gmail.com> wrote:
>
> > 2007/11/25, Chris Welton
> > <electrostatic_1 at yahoo.com>:
> > > Just because there is a registered connection
> > named
> > > "mplayerosx" with a proxy object does not mean we
> > > should assume it will respond to our messages.
> >
> > shared-buffer mode of mplayer vo_macosx only used by
> > MPlayer OS X, why
> > you think this? If for remove all warning messages,
> > maybe we should
> > set a proxy protocol for it instead of the
> > obj_msgSend call, it looks
> > a low level work of Cocoa which already be done
> > under the framework I
> > think.
> >
> > >
> > > This patch asks it before pushing data.
> >
> > As I said, I think the Cocoa already check that, if
> > obj not accept
> > some call, it will print error log and keep going.
> >
> > >
> > > Also removes redundant id to type
> > NSAutoReleasePool
> >
> > Is it necessary?
> >
> > --
> > Ulion
> > _______________________________________________
> > MPlayer-dev-eng mailing list
> > MPlayer-dev-eng at mplayerhq.hu
> >
> http://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
> >
>
> As for the autorelease pool, yes it is somewhat
> necessary, as you are leaving the other one pointing
> to an object which no longer exists.

Which object pointed by other one no longer exists? If you mean the
autoreleasepool, no other 'one' point to the autoreleasepool indeed.
The NSAutoReleasePool is some trick of Cocoa memory management, it has
'scope', after the pool released, it no longer exists, but everything
works fine since there's at least one auto release pool in the scope
when need a pool, so the 'finalPool' is there to meet the needs of the
NSApp's nextEventMatchingMask call. after this uninit scope, all Cocoa
objects already be released, no other point to any auto release pool.
That's my understanding of Cocoa memory management, you can check this
link: http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/index.html#//apple_ref/doc/uid/10000011i

> You could set
> that object to nil and then make a new one, but there
> is no real need to. One works fine.

If you mean the local variable 'NSAutoreleasePool *autoreleasepool;',
it's harmless be there after it released since when next time we init
vo, it will be allocate and inited with a new pool. After uninit and
before next preinit call, no one will use the autoreleasepool, and no
Cocoa object need to be allocated, so the code is safe looks by me.

>
> As for whether proxy automatically checks, I don't
> know, but I do know other objects don't.. I'll test
> it.

If set protocol to the proxy will fix the warnings, I will consider
fix it that way.

-- 
Ulion