Re: Background app, NSStatusItem, tight loop, event handling
Re: Background app, NSStatusItem, tight loop, event handling
- Subject: Re: Background app, NSStatusItem, tight loop, event handling
- From: Dave Hersey <email@hidden>
- Date: Thu, 05 Feb 2004 15:12:13 -0500
Hi Dave,
The "run loop calling code" I posted is being run at periodic intervals
during the tight loop "churning." I guess that could be considered to be in
an event handler since it's all executed once the "start" command has been
given.
Before I posted the original message, I had tried using
detachNewThreadSelector, but part of the processing involves using
NSURLDownload to communicate with a web server, and that broke, making me
think that locks would be an issue. The code in question is a lot more
involved than simply spinning in a loop--it communicates with a web server
and also handles operations for another application which provides a GUI.
Anyway, I'll try spinning off a thread at a lower level, past the
NSURLDownload code and see if that works better.
Thanks for everyone's input.
- Dave
On 2/5/04 2:41 PM, "Dave Camp" <email@hidden> wrote:
>
I'll start by saying I'm no expert on the inner workings of RunLoops.
>
:-)
>
>
It's not obvious where the code you posted is being run. I assume it's
>
being run from within an event handler of some sort (i.e in response to
>
your menu being clicked). Thus, you are trying to run the run loop
>
while the run loop is processing the current event. From past
>
experience I've discovered that the current run loop will not continue
>
to process the event queue until processing on the current event is
>
complete (i.e. you do something in your handler and return control). I
>
suspect it is designed this way on purpose to prevent reentrancy issues
>
which would make for some serious coding headaches.
>
>
The correct way to handle tasks that require a long time to complete,
>
and thus block event processing on the main thread, is to run the task
>
in it's own thread. As someone else mentioned earlier, this is easily
>
done with:
>
>
NSThread and detachNewThreadSelector:toTarget:withObject:
>
>
Locking issues come into play when the main thread needs to get/set
>
information that may be shared with the thread. Read the section in the
>
Cocoa docs about NSThread and NSLock. If your needs are simple, you can
>
probably just create an NSLock in the object to be run on the separate
>
thread and have all your get/set methods lock/unlock when accessing
>
member variables. If your needs are more complex, you might need more
>
locks, conditional locks, etc.
>
>
Hope that helps,
>
Dave
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.