• 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: NSXMLParser in background thread crashing
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSXMLParser in background thread crashing


  • Subject: Re: NSXMLParser in background thread crashing
  • From: Sherm Pendley <email@hidden>
  • Date: Fri, 23 Feb 2007 08:54:48 -0500

On Feb 23, 2007, at 7:56 AM, Justin R. Miller wrote:

On Feb 23, 2007, at 12:16 AM, Philip Q wrote:

There shouldn't be any problem with using an NSXMLParser in a separate
thread. What is a bit suspicious, is the NSAutoreleaePool being added
to -parse. Why is it being added?

When I originally ran -parse in a background thread, I got complaints of not having an autorelease pool and that memory was just leaking. So I subclassed NSXMLParser to override just the - parse method and these went away, per this:


Autorelease pools are automatically created and destroyed in the main thread of applications based on the Application Kit, so your code normally does not have to deal with them there. If you are making Cocoa calls outside of the Application Kit's main thread, however, you need to create your own autorelease pool. This is the case if you are a Foundation-only application or if you detach a thread.

http://developer.apple.com/documentation/Cocoa/Conceptual/ MemoryMgmt/Concepts/AutoreleasePools.html#//apple_ref/doc/uid/ 20000047-1041876-CJBFEIEG


The only code that I am calling in the new thread is the -parse method, so subclassing seemed the best way to accomplish this. I suppose I could also create a custom method on the calling object which creates a pool, calls -parse, releases the pool, and returns, ending the thread, but it seemed unnecessarily complex when subclassing was quite simple.

I'm not sure what sort of reasoning leads you to think that creating a new class is simpler than adding a method to an existing class - but anyway, that's not important. You need to create such a method for reasons beyond just memory management, and where you create it doesn't really matter. What *does* matter is that it has the proper signature, and -parse doesn't.


As stated in NSThread's docs, the selector that's passed to +detachNewThreadSelector:toTarget:withObject: "... must take only one argument and must not have a return value." NSXMLParser's -parse method takes no argument and has a return value, so it doesn't meet the requirements.

sherm--

Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net


_______________________________________________

Cocoa-dev mailing list (email@hidden)

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


  • Follow-Ups:
    • Re: NSXMLParser in background thread crashing
      • From: "Justin R. Miller" <email@hidden>
References: 
 >NSXMLParser in background thread crashing (From: "Justin R. Miller" <email@hidden>)
 >Re: NSXMLParser in background thread crashing (From: Jim Correia <email@hidden>)
 >Re: NSXMLParser in background thread crashing (From: "Philip Q" <email@hidden>)
 >Re: NSXMLParser in background thread crashing (From: "Justin R. Miller" <email@hidden>)

  • Prev by Date: Re: NSXMLParser in background thread crashing
  • Next by Date: Re: Disabling Menu Items.
  • Previous by thread: Re: NSXMLParser in background thread crashing
  • Next by thread: Re: NSXMLParser in background thread crashing
  • Index(es):
    • Date
    • Thread