You are viewing a plain text version of this content. The canonical link for it is here.
Posted to j-dev@xerces.apache.org by "Theoharis, Harry" <HT...@lehman.com> on 2000/06/08 10:23:17 UTC

Threading question

Guys (and girls),

I am using the xerces 1.0.3 and have a threading question.

I had a pool of XML container objects that use a common static parser to
"fill up their data" by parsing an XML String.

These can be asked to load from a number of threads and so they get a mutex
before and release it just at the end of the endDocument callback.

It seems to me that the parser is doing stuff after the endElement since I
was still getting some "Parse in progress errors".  Is this true?

In any case I now create a new parser for every container and so this is
irrelevant but I wouldn't mind to know anyway.  It would be nice to be able
to profile which solution is faster the "one parser but lot's of locking" or
the "no locking but many objects" option.

Regards,
Harry




Re: Threading question

Posted by Andy Clark <an...@apache.org>.
"Theoharis, Harry" wrote:
> It seems to me that the parser is doing stuff after the endElement since I
> was still getting some "Parse in progress errors".  Is this true?

You can only assume that the parser is re-entrant beginning and
after the parse method. In addition, if this is DOM parsing,
you'll want to query the document reference before releasing
your lock.

> It would be nice to be able to profile which solution is faster the 
> "one parser but lot's of locking" or the "no locking but many objects" 
> option.

No locking at all is faster but it's at the expense of using more
memory to have dedicated parser objects. And we're not just talking
about the overhead for acquiring locks. There's also the time wasted
because threads are blocked waiting for the single parser to be
ready.

-- 
Andy Clark * IBM, JTC - Silicon Valley * andyc@apache.org