Re: Update Cocoa object from callback
Re: Update Cocoa object from callback
- Subject: Re: Update Cocoa object from callback
- From: "Mark's Studio" <email@hidden>
- Date: Wed, 21 May 2003 12:59:30 +0200
Thanks
here is what i did.
if(readPointerAdder % 16384 == 0)
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[[NSNotificationCenter
defaultCenter]postNotificationName:@"playCursorUpdate"
object:[NSNumber numberWithUnsignedInt: readPointerAdder +
playRange.location]];
[pool release];
}
It's only posted every 16th callback, so it seems to work.
But what should i use if i needed to have several updates within each
callback?
I've put the NSNotification inside a NSAutoreleasePool so i don't get
the leak,
i used NSNotification because i don't have access to the object that
should perform the selector.
but what is the difference from using "performSelectorOnMainThread"
will the object that receive the notification not draw on the main
thread anyway?
On onsdag, maj 21, 2003, at 12:15 Europe/Copenhagen, Brian Willoughby
wrote:
>
[ Calling most of Cocoa's API requires doing so within a block
>
[ guarded by an autorelease pool. The threads that Cocoa owns itself
>
[ will arrange for this to be true. However, you are on your own
>
[ when you are executing code on threads not owned by Cocoa, like
>
[ the CoreAudio threads.
>
>
Generally, it is a good idea to create an autorelease pool in any
>
additional
>
threads you create, so long as it will not present a performance
>
problem. The
>
CoreAudio and CoreMIDI threads are examples where you do not want the
>
overhead
>
of a pool.
>
>
[ When I find myself in a situation where I need to call back into
>
[ Cocoa, I do one of two things. Either I explicitly create an
>
[ autorelease pool around the block of code in question or, more
>
[ usually, I make use of
>
[ -performSelectorOnMainThread:withObject:waitUntilDone: to be sure
>
[ the work I'm doing gets done on a known safe-for-Cocoa thread.
>
>
You can also create an NSPort object, set its delegate to the object
>
you want
>
to be notified, and add this port to the current run loop in default
>
mode.
>
Then you can "signal" your main application event loop from a extra
>
thread, and
>
the -handlePortMessage: method will be called. You still have the
>
problem of
>
sending the port message without using any autorelease pool. Here is
>
an
>
example ripped from my code which works without a pool:
>
>
{
>
NSDate *date = [[NSDate alloc] initWithTimeIntervalSinceNow:10];
>
NSPortMessage *portMessage = [[NSPortMessage alloc]
>
initWithSendPort:port
>
receivePort:nil components:nil];
>
[portMessage sendBeforeDate:date];
>
[portMessage release];
>
[date release];
>
}
>
>
Using NSPort like this is a bit unwieldy, and it may not be the best
>
choice,
>
but it does work just fine. I suspect that
>
-performSelectorOnMainThread:withObject:waitUntilDone: is using NSPort
>
messaging to get its job done. I think that most of the Distributed
>
Objects
>
facilities work similarly, but it's been a while...
>
>
Brian Willoughby
>
Sound Consulting
>
_______________________________________________
>
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.
>
>
Peter Mark
Mark's Recording Studio A/S
Lundeskovsvej 3 2900 Hellerup
Denmark
Tel: +45 35366078 Fax: +45 35366038
www.marks-studio.dk
email@hidden
_______________________________________________
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.