Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: [xml-dev] SAX and parallel processing

From: david.lyon@------------.---
To: "Alan Gutierrez" <alan-xml-dev@-----.--->, "Bob Foster" <bob@------.--->
Date: 1/2/2005 3:26:00 AM
There a a number of ways of doing parrellel processing
with xml;

One is to do the parsing on one machine, and fire
off the events to another. The other is to replicate
the processing code so that an xml message can be
processed accross a number of machines on the network.

Usually, there are lots of spare machines sitting
around (idling). Then, a user wants to do something
quickly (with xml), so the message gets dispatched
to any spare machines that then pick up the task
and start work.

This is really cool. Certainly presents an alternative
to the old "rewrite in assembly language" to get things
to work a bit faster.

I noticed the other week there is venture capital being
thrown at this stuff. 

Regards

David



-----Original Message-----
From: Alan Gutierrez <alan-xml-dev@e...>
Sent: Fri, 31 December 2004 14:59:21
To: Bob Foster <bob@o...>
Cc: David Megginson <david.megginson@g...>, xml-dev@l...
Subject: Re: [xml-dev] SAX and parallel processing

* Bob Foster  [2004-12-31 19:37]:
> Bob
> 
> Alan Gutierrez wrote:
> > * Bob Foster  [2004-12-31 18:03]:
> >>I have a question, though. What is the guaranteed lifetime of an object
> >>appearing in a SAX event, like an Attributes object, and any objects
> >>used to implement it? If, for example, Attributes were implemented as a
> >>collection of lightweight Attribute objects that were re-used for
> >>subsequent events, the event data could not be passed directly to
> >>parallel threads without copying it. (Or by joining at the end of every
> >>event, which would rather limit the parallelism.)
> >
> >
> >
> >     Xerces recycles Attributes structures for each call to
> >     startElement.

> >     In my library, I keep a stack of attribute structures. The
> >     attribute structures on the stack are recycled for each element
> >     depth, not actually popped and reallocated.

> Right. In order to process a SAX stream in parallel you have to
> copy the data in the stream, you can't just "forward" the events.
> You also have to instantiate a context for each event, including
> at least the namespaces in scope, the Location info. I didn't mean
> to imply this would be excessively expensive, just not as
> lightweight as serially processed SAX.

    Wasn't out to school you, so much as to relate my experience.

    Cheers.

--
Alan Gutierrez - alan@e...

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org , an
initiative of OASIS 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager:


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent