[Expat-discuss] Exiting expat handlers

[Ken Johnston]

Thanks for the feedback. The setjmp/longjmp solution won't work for me
since this application is a long running multi-threaded server and the
setjmp/longjmp functions are not thread safe (at least not on Solaris).
Looks like the best answer for now is to flag the error, set null
handlers, and keep checking for future Expat releases.

Thanks again,
- Ken Johnston

> -----Original Message-----
> From: Fred L. Drake, Jr. [mailto:fdrake@acm.org]
> Sent: Monday, October 28, 2002 5:19 PM
> To: klj@donnell.com
> Cc: expat-discuss@libexpat.org
> Subject: Re: [Expat-discuss] Exiting expat handlers
> 
> 
> Ken Johnston writes:
>  > I would be very interested in finding out about option b). Is there
any
>  > way in ANSI C (not C++) for a handler which detects an application
> error
>  > to cause XML_Parse to abort parsing and return immediately to the
> caller
>  > (of XML_Parse)? It doesn't have to return with an error or clean up
the
>  > parse object. That could all be flagged in the user data from the
>  > handler that found the error.
> 
> I'm afraid the support for this isn't very good in the current API.
> What I do for the Python bindings is, if an exception is raised by
> Python, remove all the callbacks (which avoids some overhead, but not
> the actual parsing), and installs a special handler for the external
> entity reference handler that simply reports that an error has
> occurred (CVS version of PyXML only, for any Python users out there).
> 
> The setjmp/longjmp approach, described by someone else on the list,
> can certainly work, but can cause problems for long-running processes
> that keep lots of objects on the heap but maintain lifetime
> information on the stack, so you need to be careful with that
> approach.
> 
> We are planning to improve this situation in a future release, but
> haven't had time to work on it recently.
> 
> 
>   -Fred
> 
> --
> Fred L. Drake, Jr.  <fdrake at acm.org>
> PythonLabs at Zope Corporation