Re: using performSelectorOnMainThread to update the ui
Re: using performSelectorOnMainThread to update the ui
- Subject: Re: using performSelectorOnMainThread to update the ui
- From: Jeff Moore <email@hidden>
- Date: Sun, 15 Nov 2009 14:38:28 -0800
On Nov 15, 2009, at 2:25 PM, Aran Mulholland wrote:
> does this mean that storing your data in objC data structures is a no no?
>
> or is it just that we shouldnt do anything that creates objects?
If storing your data involves invoking an ObjC method, then you shouldn't do it. Just reading/writing into memory somewhere is fine. The sure way to know is if it involves calling ObjC dispatcher. Just be aware of the GC implications of what you are doing as I mentioned.
> if you cant notify your ui from the render thread, then is the only
> other option writing information to shared data and continually
> polling it from the ui? ( i cant think of any other way off the top of
> my head )
You can call things like pthread_cond_signal() or send a mach message (provided you are using send-once right) or do any one of a number of other things. The only catch is you have to use an API/mechanism that doesn't block.
> On Mon, Nov 16, 2009 at 4:23 AM, Jeff Moore <email@hidden> wrote:
>> I'm glad you figured out your leaks. But, you should not be making any ObjC calls from any CoreAudio render/IO context. The reasons for this are several:
>>
>> - If you app is garbage collected, you cannot allocate or deallocate (and should probably not even touch) GC'd memory from the IO thread. The threads that CoreAudio uses for IO are not collectable nor are they examined by the GC. Doing something that might invoke the collector from the IO context can result in blocking the IO thread which will cause glitching. Conversely, if the IO thread retains a reference to a GC'd object, the GC will not know anything about it. This will cause a crash if the object gets collected out from under the IO thread.
>>
>> - ObjC method dispatches can block in general. There are several locks inside of a call to the ObjC method dispatcher that can block without bound. If you hit any of these, you will cause a glitch.
>>
>> - The -performSelectorOnMainThread: family of methods in particular are defined to block when called from off of the main thread so they can insert your request into the appropriate queue. Needless to say, hitting this will also glitch.
>>
>> In the long run, it's probably worth figuring out how to avoid updating your UI from the render context. It's just asking for trouble.
>>
>>
>> On Nov 15, 2009, at 3:07 AM, Aran Mulholland wrote:
>>
>>> scratch this, i had nszombie enabled, no leaks without it.
>>>
>>> thanks
>>>
>>> aran
>>>
>>> On Sun, Nov 15, 2009 at 7:30 PM, <email@hidden> wrote:
>>>> hey all,
>>>>
>>>> in my render callback i want to update the ui. im working on the iphone and
>>>> seem to be getting memory leaks when i call performSelectorOnMainThread to
>>>> notify the ui that it needs to redraw. Is this because the audio thread
>>>> lacks an autorelease pool?
>>>>
>>>> whats an effective system for doing this. Do i have to start an nstimer on
>>>> the main thread and continue to redraw the ui from there? or can i send the
>>>> message (without the leaks) somehow?
>>>>
>>>>
>>>> thanks
>>>>
>>>> aran. - sunday afternoon, memory leaks.
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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