NSXMLParser thread safe?

  • Hi all,

    Just wondering if anyone knows whether NSXMLParser is thread safe. I'm using it to parse SVG files - when I do it threaded, I get a crash in [NSXMLParser parseData:], unthreaded it works fine.

    If I know it should be thread-safe, I can look to see whether anything in the parser's delegate is not thread-safe even though it appears to crash in the NSXMLParser itself. The documentation doesn't say one way or the other.

    --Graham
  • On May 31, 2012, at 10:45 PM, Graham Cox wrote:

    > Just wondering if anyone knows whether NSXMLParser is thread safe. I'm using it to parse SVG files - when I do it threaded, I get a crash in [NSXMLParser parseData:], unthreaded it works fine.
    >
    > If I know it should be thread-safe, I can look to see whether anything in the parser's delegate is not thread-safe even though it appears to crash in the NSXMLParser itself. The documentation doesn't say one way or the other.

    From the Lion release notes for Foundation:

    "NSXMLParser Thread Safety

    NSXMLParser is now threadsafe. However, it is not reentrant on a given thread; don't call -parse on an NSXMLParser from within a delegate callback of another NSXMLParser."

    Regards,
    Ken
  • On 01/06/2012, at 1:50 PM, Ken Thomases wrote:

    > From the Lion release notes for Foundation:
    >
    > "NSXMLParser Thread Safety
    >
    > NSXMLParser is now threadsafe. However, it is not reentrant on a given thread; don't call -parse on an NSXMLParser from within a delegate callback of another NSXMLParser."

    Ah, thanks. I'm not doing that.... must be something else.

    I wonder if it's a stack space issue? I'm getting EXC_BAD_ACCESS with code 13 - where are these codes listed? Is there a way to increase stack space for a thread?

    --Graham
  • On May 31, 2012, at 11:36 PM, Graham Cox wrote:

    > I wonder if it's a stack space issue? I'm getting EXC_BAD_ACCESS with code 13 - where are these codes listed? Is there a way to increase stack space for a thread?

    That depends. How are you creating the thread? It isn't difficult to do using either the pthread or NSThread APIs.

    Nick Zitzmann
    <http://www.chronosnet.com/>
  • On 02/06/2012, at 1:55 AM, Nick Zitzmann wrote:

    > That depends. How are you creating the thread? It isn't difficult to do using either the pthread or NSThread APIs.

    Well, I started with the NSThread method that I've used classically, but moved it over to using NSInvocationOperations in a NSOperationQueue. This second approach is easier, and more stable, but I found a few places where things were going pear shaped, mostly to do with accessing shared caches, which was easily dealt with using @synchronised blocks.

    I'm still getting the occasional crash if I let the operation queue perform more than one operation at a time (i.e. it has a limit of 1, but runs it on a thread other than main, and that's OK, but for 2 or more, it sometimes falls over).

    I think this has convinced me that there's something not quite thread-safe in my own code, rather than a stack space issue. While SVG parsing can sometimes end up with quite a deep stack, it's not failing specifically under those conditions.

    I'll keep working on it....

    --Graham
  • On Jun 1, 2012, at 4:18 PM, Graham Cox <graham.cox...> wrote:

    >
    > On 02/06/2012, at 1:55 AM, Nick Zitzmann wrote:
    >
    >> That depends. How are you creating the thread? It isn't difficult to do using either the pthread or NSThread APIs.
    >
    >
    > Well, I started with the NSThread method that I've used classically, but moved it over to using NSInvocationOperations in a NSOperationQueue. This second approach is easier, and more stable, but I found a few places where things were going pear shaped, mostly to do with accessing shared caches, which was easily dealt with using @synchronised blocks.

    It's important to note that operation queues (and dispatch queues for that matter) do not guarantee anything about what threads your operations execute on. Apple's notoriously slippery definition of "thread-safe" can still bite you if the implication is that an NSXMLParser instance is safe to use from a non-main thread as long as *all* uses are from the *same* thread. That would make it unsafe to access the same NSXMLParser instance from two different NSOperations.

    --Kyle Sluder
  • On 1 jun 2012, at 18:15, Kyle Sluder wrote:

    > That would make it unsafe to access the same NSXMLParser instance from two different NSOperations.

    Not necessarily. It all depends on the context of where the operations are executing.

    Joar
  • On 02/06/2012, at 11:15 AM, Kyle Sluder wrote:

    > It's important to note that operation queues (and dispatch queues for that matter) do not guarantee anything about what threads your operations execute on. Apple's notoriously slippery definition of "thread-safe" can still bite you if the implication is that an NSXMLParser instance is safe to use from a non-main thread as long as *all* uses are from the *same* thread. That would make it unsafe to access the same NSXMLParser instance from two different NSOperations.

    Right, thanks for the clarification.

    In this case, it's not the same NSXMLParser instance - it's a new instance for each file I need to parse.

    I found the source of my crashes - I was sharing an NSTextLayout object among the different objects used to layout text. Previously that worked on the main thread because only one was in use at a time, but it's not thread-safe. Making a new instance each time fixed that problem.

    A similar issue concerned the use of [NSFileManager sharedManager] - making that a new instance instead allowed access from several threads (I believe this particular case is documented).

    There are still some shared objects, such as the NSFontManager, but that hasn't caused any problems so far.

    --Graham
previous month june 2012 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  
Go to today