Re: retain+release (Re: kAudioUnitProperty_ContextName)
Re: retain+release (Re: kAudioUnitProperty_ContextName)
- Subject: Re: retain+release (Re: kAudioUnitProperty_ContextName)
- From: William Stewart <email@hidden>
- Date: Tue, 27 Jul 2004 19:21:33 -0700
The standard semantic for CF objects with AU's is that the host
retrieves a copy that it releases when *it* is done with it. This is
the safest path so that:
(1) If the AU releases it before the host is finished with it, it
doesn't crash
(2) The host releases it before the AU is finished with it, it doesn't
crash
So, using this semantic the AU has its own version (retain count) on a
string it has, and the host has its as well. That's the basic semantic
(with one exception described in the CFAU doc in the SDK) and there is
no autorelease pool in C/C++ of course.
Bill
On 27/07/2004, at 4:12 PM, Brian Willoughby wrote:
>
[ >> 2) ContextName is not covered in CF_AU_Properties.text nor are
>
its
>
[ >> CoreFoundation semantics covered in the regular docs for the AU
>
API:
>
[ >> /Developer/Documentation/CoreAudio/AudioUnits/Topics/
>
[ >> au_properties.html#kAudioUnitProperty_ContextName
>
[ >> I am guessing that it is the norm (the AU creates or retains the
>
[ >> value for the client on GetProperty, and retains the new value on
>
[ >> SetProperty), but it seems to me like this should be explicitly
>
[ >> stated somewhere.
>
[ > I'd definitely vote for following the norm.
>
[
>
[ When the property is Set - the AU should retain the string (so
>
[ ultimately it might have the only reference to it).
>
>
So far, so good...
>
>
[ When the property is retrieved, the AU should also retain the
>
string,
>
[ so it always has a retain on the string it is holding. The host
>
should
>
[ release the string it retrieves from Get Property when it is
>
finished
>
[ with it.
>
>
Perhaps I misunderstand, but this seems to break the typical
>
object-oriented
>
design paradigm. Retain and release pairs should never be handled by
>
different
>
objects. Each use of a string object should be retained and then later
>
released by the same object. This isn't always possible, though,
>
which is why
>
autorelease was designed, but autorelease only works when there is a
>
pool in
>
place. In the case you describe above, if the AU retains a string
>
that it is
>
returning to the host, then it should autorelease that string. The
>
host should
>
be responsible for retaining the string only if it needs to hold on to
>
the
>
string longer than the current pool context, if any, and release it
>
later.
>
>
The other alternative would be for the host to retain the string as
>
soon as it
>
receives it from Get Property, and release it when done.
>
>
What I have described was established as a standard design paradigm in
>
Objective C, and should be confirmed throughout the Cocoa
>
documentation. I'm
>
less familiar with the standard C implementations of these concepts,
>
but I
>
really hope the ease of use has not been compromised by increasing the
>
responsibilities of one object for another object.
>
>
[ The property can be cleared by setting the property with a NULL
>
value
>
[ (so the AU *has* to check for NULL before retaining the value when
>
the
>
[ property is set)
>
>
No problem.
>
>
Brian Willoughby
>
Sound Consulting
>
>
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
Culture Ship Names:
Ravished By The Sheer Implausibility Of That Last Statement [GSV]
I said, I've Got A Big Stick [OU]
Inappropiate Response [OU]
Far Over The Borders Of Insanity And Still Accelerating [Eccentric]
________________________________________________________________________
__
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.