Re: Don't exchange pointers, was Re: Objective-C++/C++ with CocoaUI Issue...
Re: Don't exchange pointers, was Re: Objective-C++/C++ with CocoaUI Issue...
- Subject: Re: Don't exchange pointers, was Re: Objective-C++/C++ with CocoaUI Issue...
- From: Robert Abernathy <email@hidden>
- Date: Tue, 20 Jun 2006 20:21:07 +0100
I should have been more clear. In the instance where I pass data to
the AU from the UI, the structs are allocated and filled out in the
UI. I then pass a pointer to them in AudioUnitSetProperty. When I
get the corresponding call in the AU, I copy the data into a local
struct in the AU. It works flawlessly in my experience. Sorry for
adding any confusion.
On the other point of VNC vs. X-Windows, can we please stick with the
architected solution? For one thing, what to do if the processing
node has no UI capability at all? What if the processing node is
actually a collection of nodes controlled by one UI? It seems to me
that the current solution can work in either of these situations (and
many others) with no problems. We just need some hosts to do it.
Rob
On 20 Jun 2006, at 19:11, William Stewart wrote:
The Filter's view allocates a block of memory that points to an
array of typedef struct FrequencyResponse (defined in Filter.h)
When retrieving the values for these, the view passes a pointer to
this block of memory and sets the size of the property to be the
allocated size of this memory. The AU then sets the frequency
response values into that memory.
In this scheme, there is no assumption that a view and its AU are
running in the same address space. Some code can intervene in the
middle of this process and pass the memory to/from the view/AU. The
AU does not hold onto this pointer for later use, so it has no
assumptions about it except as some address to write data too when
it is called.
As a side note, the property is also implemented as an "on demand"
property - the AU is not precalculating these values and storing
them in local memory, but rather when queried the AU does the work,
writing the results of that work to the supplied memory location.
All of the standard AU properties are implemented in this manner -
the AU will either use the passed in value or copy the struct (for
instance SetFormat) so that there are no dependencies or questions
of ownership.
By "passing pointers" what is being referred to is the deliberate
passing of a pointer (for example a this pointer) between the AU
and the view and then what happens to the usage of that pointer.
For instance, a View retrieves the this pointer from the AU, then
proceeds to make method calls on this this pointer (or directly
access data members). To take the example above, it would also be
problematic if the AU having been given a pointer from this
property call, would then turn around and cache this pointer
internally and at some later time read or write to that memory. In
both of these cases, the code that uses the pointer after the call
completes assumes that the pointer is still valid, that the pointer
is always in the same address space, etc..
Bill
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden