Threads Question
Threads Question
- Subject: Threads Question
- From: Philippe Sismondi <email@hidden>
- Date: Wed, 17 Mar 2010 10:36:40 -0400
I am hoping to add some functionality to an existing open source app (Skim) that uses threads for fairly simple purposes. (I believe Grand Central Dispatch etc. are not an option - I don't know whether this would be useful anyway as I have not learned about GCD.)
I have read the Threading Programming Guide twice, but am still unsure how to design this. I am not very expert with threading.
From this app I want to launch another existing utility (ghostscript) and get its output back into the main app. Skim is a document-based app. The invocation of ghostscript will be done by means of the Open File menu item; a new MyDocument instance will be created thereby.
Because the length of time that this secondary task takes is highly variable, I want to be able to cancel its processing from the main app. So, I want to launch the secondary task in a separate thread to keep the main runloop responsive. (This is of course a very common GUI issue.)
I have some existing code from the main app that does this. As you may see below, it uses the beginModalSessionForWindow call, and calls runModalSession in a loop. The problem that I see is that this design does not really "respect" the intended use of beginModalSession et al. in that no real work is done in the loop - all work is done on the detached thread. I believe that in fact the loop is effectively a tight loop that chews up a lot of resources polling for the detached thread to complete.
As indicated by the comment in the code fragment below, using runModalForWindow seems to create some timing problems - it is possible that the detached thread may complete before runModalForWindow even starts.
My question may be a bit broad to answer here, but anyway, here it is:
Can anyone point me in the direction of a design that:
(a) allows the detached thread (actually the NSTask launched within the thread) to be terminated from a modal main thread window, and
(b) does not chew up resources in a busy-waiting loop?
Thanks, and here is the existing code fragment (from the Skim application):
/***************************************/
- (NSInteger)runModalSelector:(SEL)selector withObject:(NSDictionary *)info
{
Nsmodalsession session = [NSApp beginModalSessionForWindow:[self window]];
BOOL didDetach = NO;
NSInteger rv = 0;
while (YES) {
// we run this inside the modal session
// since the thread could end before runModalForWindow starts
if (NO == didDetach) {
[NSThread detachNewThreadSelector:selector toTarget:self withObject:info];
didDetach = YES;
}
rv = [NSApp runModalSession:session];
if (rv != NSRunContinuesResponse)
break;
}
[NSApp endModalSession:session];
// close the window when finished
[self close];
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden