• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Endless loop but only with release build
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Endless loop but only with release build


  • Subject: Re: Endless loop but only with release build
  • From: Antonio Nunes <email@hidden>
  • Date: Sun, 1 Oct 2006 14:16:54 +0100

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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Endless loop but only with release build
      • From: Mike Abdullah <email@hidden>
  • Prev by Date: Cocoa view overlap bug in Logic Express 7.1?
  • Next by Date: Re: Re: Weird drawing trouble, please help me
  • Previous by thread: Re: Cocoa view overlap issue in Logic Express 7.1.1 and Logic Pro 7.2.3
  • Next by thread: Re: Endless loop but only with release build
  • Index(es):
    • Date
    • Thread