[fpc-devel] XML DOM thread safety

Inoussa OUEDRAOGO inoussa12 at gmail.com
Wed Nov 11 13:18:16 CET 2009


Hi

I would like to point out ( again, the third time ) that up to now ( I
just checked out 2.4-rc1 and trunk ) there is _no safe_ way to use the
"fcl-xml" package in a multi threaded environment. I mean, even if
your xml DOM instances are private to
their thread, _not accessed_ by other threads, used independently,
still you are not safe.


This situation is due to the dependency
of the DOM implementation, specifically the "TDOMNode_WithChildren",
upon the "TAVLTree" class ( see fcl-base\avl_tree.pp ).
"TAVLTree" _by default_ uses a _shared not protected_ node manager and
that has the consequence that every code
that depend on this class is fundamentally not thread safe.

Because of this, one cannot do serious enterprise server side
development with FPC 2.2.x without patching
the base packages, and this is causing serious threats to FPC. Please
consider removing the TAVLTree dependency as
proposed by Sergei Gorelkin or use, by default, a thread safe node
manager. I can provide a patch( as I already did ) for
a default thread safe node manager that does not pooled the objects.
Note that Marco van de Voort provided and applied a
patch that allow the change of an instance node manager, but that does
not address the base problem of the default usage.

I do think that an implementation optimization does not have to make a
_default_ usage of a class not safe. More over a
basic data structure that is used by other base classes in the _default_ way.

It will be very disappointing and sad to see another FPC release with
this problem.

PS : More infos about the thread safety
  Given :
    * 2 threads , ThreadA and ThreadB, each thread having an instance
of TDOMDocument
    * The threads does not communicate
    * The treads are not aware one about the other
    * each thread access _only_ its _own_ instance of TDOMDocument
still, you are not safe. The problem is present even if no instance is shared.

Best regards.

-- 
Inoussa O.



More information about the fpc-devel mailing list