Re: [xml] test the current state

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 Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

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