Re: [xml] libxml2 thread safety (SUMMARY)

On Wed, 3 Oct 2001, Gary Pennington wrote:

Thirdly, If we do decide that backwards compatibility is not an issue.
Then there are many measures that can be taken to improve the library.
New re-entrant APIs for setting state using user supplied storage,
remove all global state, etc... However, I don't believe this is a
realistic solution as it will cause major compatibility issues for the
existing user base. Let's keep discussing this, but I believe that
backwards compatibility is right at the top of the design goals for
any change to the library.

What about providing a new set of APIs which take a configuration
structure and, for backwards compatibility, make all of the old APIs call
the new ones, transparently using TSD for the configuration structure?

Old code still works as it did and new code can be completely thread-safe.
New code would even be able to run two separate parsers on the SAME thread
which I don't think has been mentioned (although it's less likely to be
useful, I admit).

The disadvantage is that there's two copies of most of the APIs and maybe
that is too difficult to maintain.

Sorry if this is a bad idea but I like it because old code still works
but the quality of the library isn't held back by it. Whatever happens,
I'm greatful just to have LibXml in the first place.



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