OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] SAX and parallel processing

[ Lists Home | Date Index | Thread Index ]


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@engrm.com>
Sent: Fri, 31 December 2004 14:59:21
To: Bob Foster <bob@objfac.com>
Cc: David Megginson <david.megginson@gmail.com>, xml-dev@lists.xml.org
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@engrm.com

-----------------------------------------------------------------
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:




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS