On 11 Oct 2009, at 20:40, John Love wrote:
Reference:
http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html#//apple_ref/doc/uid/10000057i-CH16-SW29
As noted, Apple's sample code sends a kCheckinMessage back to the
main Thread and then monitors the currentRunLoop until -shouldExit
returns YES. Within -shouldExit, I wish to monitor error conditions
(e.g., a external application's document not open). If such an
error exists, send a unique error message ID and then return NO when
-shouldExit is finished.
Is -shouldExit the appropriate place for sending these other message
IDs?
Not really, no. Why should a method called -shouldExit do such a
thing? It is, obviously, up to you what -shouldExit does (since it's
a method defined by MyWorkerClass, which is entirely your business),
but it seems inappropriate for it to do things unrelated to testing
whether or not the thread should exit.
Also, there's no guarantee that the run loop will return regularly,
unless you set some other date besides +distantFuture... As an aside,
however, polling is *really ugly* and wastes both energy and CPU time,
so ideally if you can avoid it then you should; whether this is
possible depends on the tests you need to do.
FWIW, it seems like quite a complicated design using this Mach port
sample as a basis for the kind of thing you're proposing. How are you
proposing to do your checks, precisely? Why not just use a thread and
-performSelectorOnMainThread:?
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
Cocoa-dev mailing list ([email protected])
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
