RE: Leak while in Midi thread
RE: Leak while in Midi thread
- Subject: RE: Leak while in Midi thread
- From: "Benjamin Golinvaux" <email@hidden>
- Date: Sat, 11 Jan 2003 17:59:39 +0100
How about having a queue (that has a **non-blocking** method to add
items), and, from the midi proc, add to this queue the information
needed to update your display (without Cocoa code). Then, you can use
the semaphore_signal() call (**) to wake up another thread (that you
have created) that will pop an item off the queue and update the
display. I have experienced very weird issues when calling some app kit
routines from several threads (even when closely following all the
recommandations for doing this) so if you want to be really safe, you
can, from the queue-reading thread, use the :
-(void) [NSObject performSelectorOnMainThread:(SEL)aSelector
withObject:(id)arg waitUntilDone:(BOOL)wait]
selector to actually perform AppKit calls (this method schedules the
selector call on the object sometimes later in the main appkit thread).
If you set the waitUntilDone param to NO, your calling thread won't be
blocked (at least not for a long time (?)) (this will only work if the
OS version is >= 10.2)
This looks like a complex way of doing things (and I'd be glad to hear
someone who has a simpler way of doing the same), but this really gives
you fined-grained control : you can design your queue so that you
display code doesn't get flooded with too many messages by
filtering/suppressing them in the "3rd" thread and you are also
guaranteed not to block the real time thread if you are careful.
Hth
Benjamin Golinvaux
(**) semaphore_signal() seems to be the only guaranteed non-blocking way
of waking-up a thread, according to what Kurt Revis found out (see the
"Can pthread_cond_signal() block?" thread in this mailing list for
details), and if I understood this correctly. Btw, thanks to Kurt for
finding this invaluable information...
-----Original Message-----
From: email@hidden
[
mailto:email@hidden] On Behalf Of Craig Bakalian
Sent: samedi 11 janvier 2003 10:38
To: email@hidden
Subject: Re: Leak while in Midi thread
On Friday, January 10, 2003, at 09:58 PM,
email@hidden wrote:
>
Subject: Re: Leak while in Midi thread
>
From: Jeff Moore <email@hidden>
>
To: CoreAudio <email@hidden>
>
>
This discussion seems like as good a time as any to remind people that
>
allocating and deallocating memory inside a time constraint thread
>
such as this MIDI thread or the HAL's IO thead is flat out bad
>
programming. The reason why is that the memory calls _will_ block
>
(usually precisely when you don't want them to) and cause you timing
>
problems that are very hard to diagnose. This is among the reasons why
>
there are no autorelease pools in these threads.
>
>
To reiterate: don't allocate or deallocate memory in a time constraint
>
thread owned by the audio or MIDI systems. You will get hurt by doing
>
so.
So how do we get around this? I am not having timing problems because
my app is just getting the tone value or midi value of each midi key
press and I am using the numeric key pad to enter the rhythmic value of
a given music note. But strange things happen sometimes. Some times
the tone value does not change. What do we do when we are using Cocoa?
Craig Bakalian
_______________________________________________
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.
_______________________________________________
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.