Re: [xml] libxml2 thread safety (SUMMARY)

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.

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