Re: Endless loop but only with release build
Re: Endless loop but only with release build
- Subject: Re: Endless loop but only with release build
- From: Mike Abdullah <email@hidden>
- Date: Sun, 1 Oct 2006 14:23:53 +0100
Maybe I don't fully understand your situation here, but couldn't you
have something like:
- The secondary thread retains all the data it needs for its operations
- When asked to close, the main thread sets the flag telling the
other thread to stop
- The main thread then closes the document as usual
This way the interface should always be responsive. The only
downside is that parts of your data still take up memory until the
secondary thread quits, but that shouldn't be an issue because they
will be deallocated once that thread is done.
Mike.
On 1 Oct 2006, at 14:16, Antonio Nunes wrote:
This is turning into a very interesting and educational discussion.
- For me anyway. - I'd like to thank everybody for their invaluable
comments/pointers/advice. I understand now what is going on and why
the freeze happens, so next on the list is finding a viable solution.
I've been reading up on locks and threads etc. and looking into
different ways of solving this, looking for as simple a solution as
possible.
I'll explain a bit clearer what is going on when trying to close a
document window:
When a user imports a PDF file into my app's document, the app
starts a helper thread that converts the PDF pages in the
background to make certain future operations faster. Meanwhile the
user has full access to the newly loaded document, and almost all
functionality is available. The conversion process can be lengthy
for large PDF files. If a user decides to close a document without
saving, we no longer care for the secondary thread to finish the
conversion process, so the main thread sets a flag signalling the
secondary thread that we are closing, causing it to exit the
conversion loop on the next iteration. The current iteration
however may take longer to finish than the time it takes the
document to close the window and deallocate. If that happens the
helper thread may crash since it is trying to work on data that is
no longer valid. Hence the need to have the document stick around
until the helper thread has exited.
Trying to keep things simple and to avoid having to set up a
condition lock, I thought of another way to wait for the desired
state, blocking the current thread, but without tying up system
resources: We allow the current thread a short nap.
while (_isConverting) {
[NSThread sleepUntilDate:[NSDate dateWithTimeIntervalSinceNow:
0.25]];
}
From a user experience point of view this code seems quite
acceptable: this loop is unlikely to execute more than a very few
times, and it doesn't tie-up the rest of the system, by wasting
precious processor cycles. Is there anything against this solution?
If I really should use a condition lock, or any other kind of lock,
I may need some help learning how to set it up, event hough I've
looked at code examples and tutorials, including the one on
multithreading at cocoadevcentral, and some skeleton code showing
how to go about it would be greatly appreciated.
All the best,
António
-----------------------------------------
Forgiveness is the perfume
that the trampled flower casts
upon the heel that crushes it.
-----------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40gmail.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden