Re: [xml] libxml2 thread safety (SUMMARY)

[Daniel Veillard <veillard redhat com>]

On Wed, Oct 03, 2001 at 04:59:38PM +0100, Gary Pennington wrote:
> >   - that structure is accessed using an overridable function returning
> >     a pointer to that structure
> I'm not clear as to exactly what this means. Why would the function be 
> overridable? Is this because we want to make it possible for users to 
> maintain state in any fashion they choose? If so, I think that is not a 

  Yes. The point is that it allows the same code once compiled to run either
in a threaded or unthreaded fashion. I don't want to see libxml2-thread
and libxml2 packages ducplication exporting the same symbols but incompatible
from a run-time point of view. Major mistake, seen Sun do that in the past
(some ugly X11 threadified library versus normal ones problems) and I certainly
don't want to enter that maintenance nightmare. Second benefit is that 
the thread dependancy can be isolated from libxml itself anjd is IMHO 
a huge gain maintenance wise.

> good idea. What happens if multiple libraries all link to libxml2 and 
> choose to use different methods to maintain global state? This solution 

  Those libraries are incompatible. Would not be the first time one see
this. If one aplication uses library A and B and B uses A too, B is threaded
and the application is threaded then yes you might have a trouble.
Is this worth putting directly thread dependancies in the library.

> is appropriate for single applications, but breaks when applied to 
> libraries which use libxml2 and have no control over how libxml2 may be 
> used from other consumers inside a process adress space.

  Agreed you may have troubles.

> >   - the old name for the global variable is turned into a macro
> >     dereferencing the pointer returned by that function (I think
> >     this will keep the read/write capability of that property).
> It does. You can see how this works in the sample I sent out yesterday.

  Even for write, i.e. an application compiled now and writing to a
global var would still work ? Not what I understood.

> > Do you foresee any significant problem with this approach ? Any recompiled
> > library would work in the same mode as the application. There is a single
> > atomic step to switch to a threaded mode which is to set the global variable
> > containing the pointer to the accessor function.
> The main problem is that it requires source code to explicitly be 
> compiled to be thread-safe. In other words, the user will have to know 
> that he is planning to use libxml2 in a threaded fashion. This would be 

  If you use a thread fork in your application you better know it !!!
I don't see anything pernicious there, rather the opposite, an application
has to be conceived as thread based versus loop based nearly from the
start, saying the app designer need not know it sounds really strange
there is just so many things withc need careful attention in that case
that adding the initialization of threading explicitely for libxml seems
acceptable to me in this context.

> extremely pernicious when people start to develop and distribute 
> libraries which use this facility. How would a potential consumer of a 
> library know what assumptions the distributed library had made about 
> thread-safeness? Also, this would still be broken with respect to any 
> existing libraries and would not support binary compatibility. Finally, 
> it would be very broken if multiple libraries had to be linked against 
> and they all required different behaviour from libxml2.

  That is true

> The solution I'm proposing is, I think, very similiar to what you 
> describe above - but there are some key differences. I think that we can 
> get libxml2 to be thread-safe, backwards compatible and avoid 
> re-compiling any existing code by careful use of TSD and placement of 

  TSD == Task State Descriptors ?

  I'm really vary of adding thread knowledge at the library level itself
it *is* hard to make portable and maintain. Currently libxml is easy to port
and relatively easy to maintain. I have to resist changes which decreases 
those key properties. It may be all a matter of careful coding, but I need
to be cautious there. I may have to maintain this code for the next 10 years !

> global state in internal data structures. I don't think that what you 
> propose, user configurable global state storage, will work because of 
> the reasons I outlined.

  Okay, what do you think your approach would break ?
We basically agree on what need to be done but diverge on the way to do it,
though the core part is similar in both approaches.

Daniel

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