Re: [xml] Some things about xmlCharEncodingHandler

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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]