Re: [xml] test the current state

[Daniel Veillard <veillard redhat com>]

On Fri, Oct 19, 2001 at 09:09:36AM +0100, Gary Pennington wrote:
> I did remove it and the good news is that testThreads doesn't report any 
> failures. The scalability doesn't seem to be very high (on my 2 way box, 
> I'm using about 80% of two CPU (70% user and 10% sys), but I guess 
> that's because this test is a "destruction" test with a lot of conflict 
> during the catalog loading.

  Yes, it's a trash test whose goal is to exhibit bugs in
      - concurrent loading
      - file access resolution
      - catalog access
      - catalog building
      - validation
      - global variables thread overrides
      - and memory handling of course.

> I expect the scaling will be a lot higher if 
> we don't load catalogs each time we move through the loop.

  Yes, especially since once the catalog used parts are built they
are accessed concurrently without locking.

> I'll spend more time working with testThreads and I'll enhance it with 
> more tests and instrumentation if I can make time.

  okay, there are untested parts in that test:
   1/ saving
   2/ entities
   3/ HTML parsing
   4/ XPath
   5/ XInclude
   6/ FTP/HTTP
   
 1/ could be tested by serializing in memory and checking the output hash
 2/ 5/ could be tested by augmenting the test inputs
 3/ should probably be built as a different test, well or add just more
    input and launch them simultaneously
    I know a couple of small changes which should be made in that module.
 4/ better tested using an XSLT testbed
 6/ code review would be easier parts for checking this

Once built the tree manipulations are inherently not thread safe, so
that's left to user code synchronization if needed.

  The basic work on threads is done IMHO, I hope this will free up more time
for the other work.

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/