Re: [xml] Some things about xmlCharEncodingHandler

[Igor Zlatkovic <igor zlatkovic com>]

Oliver Stöneberg wrote:

> > Oliver Stöneberg wrote:
> >
> >
> > > Might this cause some problems, if you just change the callbacks 
> > > while libxml2 might be in use? I am not sure how it is protected or 
> > > sync'd internally. Because if somebody is using the handler while you 
> > > change it might use the first callback, which still be the old one 
> > > and then the second callback, which is already the new one. Would be 
> > > a bad thing IMO.
> >
> > While somebody is using it? Who is somebody? When your program loads 
> > libxml, its data belong to your program's address space. There can never 
> > be another who uses that. Any other process has its own address space 
> > and its own instance of libxml data.
>
>
> OK, "somebody" is the wrong wording. I meant another thread in a 
> multi-threaded enviroment. As the handler are global and when I 
> change one handler with a class, that creates XMLs and saves and at 
> the same time there is another thread, that is using the libxml2 to 
> just simply parse an existing document. IMO that might affect the XML 
> output or parsing result depending on what handler you modify. If you 
> just modify your own handler, that isn't registered by default it 
> should not have big impact, because it's quite under your control. 
> But if you e.g. overwite the UTF-8 handler while some other thread is 
> using it, the scenario about using one old and one new callback could 
> happen. Or are the handlers global in the thread-safe data? IIRC they 
> aren't because I already ran into the problem of handler being 
> cleared and causing exceptions, because another thread was still 
> working (OK, that was caused because of bad implementation)

Okay, now I must clarify: I didn't say that you should overwrite the 
handler in any libxml function. You must do it in your program's code. 
That because only your program can know how and when to do it without 
crying thereafter.

So, the only safe thing you can do to xmlNewCharEncodingHandler is to 
have it return the existing handler, if one is found. The caller, 
possibly the client application code, must then deal with the fact that 
callbacks possibly aren't the desired ones. The caller can then 
overwrite the callbacks in the returned handler at a time and in a way 
it knows is acceptable for the rest of application.

I still think you should never need to replace the default handlers for 
a given encoding. Why would you want to do that?

Ciao,
Igor