Re: [xml] Aborting html sax parsing from python

[Daniel Veillard <veillard redhat com>]

On Thu, Oct 27, 2005 at 12:04:06PM -0400, Stefan Seefeld wrote:
> Daniel Veillard wrote:
> > On Thu, Oct 27, 2005 at 10:59:33AM -0400, Stefan Seefeld wrote:
>
> > > We had a discussion some months ago concerning handling of python 
> > > exceptions
> > > raised in callbacks. The idea was to pass exceptions through the C layer
> > > such that they could be caught at (python) application level.
> > >
> > > Is this now supported ? That might be the simplest way to achieve what 
> > > the OP
> > > wants without the need to touch any low-level API.
> >
> >
> >  ECANTWORK (unless I misunderstand the proposal)
> >  you would leak all the structures allocated in the C layers between
> > the point getting the exception and the point raising it, and since it's
> > likely to include a call to reading than means an really large leak
>
> Well, if the stack unwinding is properly done no resources should be leaked.
> Let me resume the proposal:
>
> * the python application creates a parser
> * the python application calls parser.parse(...) (or equivalent)
>     o the python implementation calls the appropriate C parse function
>         * the C parse function calls (probably deep in the call stack) a 
>         callback
>              o the callback executes python code
>                  * the python code raises an exception
>              o the return value of the python function will be 0
>                (and PyErr_Occurred() will return 1), indicating an error.
>                The python exception will be stored in a global variable that
>                is part of the python runtime.
>              o at this point you tear down the parser, i.e. call 
>              xmlStopParser()
>                and generally free any temporary resources associated with 
>                the parsing.
>              o return from the parse function (possibly with some error 
>              code)
>         * the C API for python functions lets functions typically return a 
>         python
>           object (Py_None at least), so returning 0 will inform the caller 
>           about
>           the exception.
>      o the 0 return value will be caught, triggering further stack 
>      unwinding, now inside python,
>        until the original python exception is caught.
>
> So, if all this is implemented correctly, everything should 'just work'.

  Okay so the exception unwinds though the C code.
Seems though that there is a lot of work to get all cases covered,
needs to modify the handler. 
What happen in case of multithreaded apps ? the global variable is a
potentially serious problem if you do a complex setup.

> The critical thing is thus to check for callback failure. There is nothing 
> special
> you have to do to pass the exception through, since both the callbacks and 
> the application
> code share the same python runtime, i.e. see the same state that stores the 
> exception
> somewhere.

  This doesn't look that easy to implement right, there is a number of
pitfall I believe. I won't have time to do this in the foreseable future, but
if you want to work on it, I take patches :-)

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/