Re: [xml] libxml2 thread safety (SUMMARY)

[Bjorn Reese <breese mail1 stofanet dk>]

Daniel Veillard wrote:
> On Thu, Oct 04, 2001 at 11:43:26AM +0100, Gary Pennington wrote:

> > >    - export the locking as a libxml function and data to help portability,
> > >      this is not a full encapsulation of a thread system, just the
> > >      create/lock/unlock/destroy of a lock since it will be used in other
> > >      places in libxml (and possibly libxslt too).
> > I would propose adding two functions to support locking/unlocking of the
> > parser context. I don't think that I will export the lock create/destroy
> > since that is internal to the library and should have nothing to do with
> > any consumers. I'll think more about the utility of internal
> > functions/macros to do this.
>
>   I would need to add locking to XPath and Catalog implementation.
> This mean I need to create and destroy locks. I want an uniform way to
> do this within the library.

I have not been following this thread closely, so I appologize in advance
if I repeat the obvious.

Locking/unlocking is specific for the threading model in use. Libxml is a
library and should not assume any specific threading model. So I suggest
that libxml uses callback functions for the locking/unlocking. Then the
application, which knows what threading model is used, can provide the
specific locking/unlocking mechanisms. If no callback functions are
provided, then no locking takes place, which is perfectly fine for
non-threaded applications.