W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > April 2007

Re: Synchronisation

From: Alessandro Vernet <avernet@orbeon.com>
Date: Wed, 4 Apr 2007 21:12:32 -0700
Message-ID: <4828ceec0704042112s3aa8757br2d38385eb325844f@mail.gmail.com>
To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>

On 4/4/07, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
> Thinking more about Norm's dependency example, I realise I think we
> need to be _very_ modest in what we require in terms of guarantees of
> order of execution.  As an illustration, I propose a thought
> experiment about implementation -- suppose I am worried about
> deadlocks and buffering and all that, and so I take the simplest
> possible approach: I create a new thread for _every_ step in a
> pipeline, connect up the inputs and outputs, and start all the threads
> running simultaneously.  Is there anything in the spec. which rules
> this out?  I don't think so, and in fact I think it's a pretty good
> implementation strategy.

Yes, I fully agree. And while the implementation strategy you describe
might be excellent in some scenarios, it won't be in others. For
instance in our implementation, we are very much preoccupied by
performance. So starting a thread for each step wouldn't really work
for us.

> I'm reminded of a point I've made before about pipelines --  they are
> _much_ easier to understand in terms of dataflow.  Adding a story
> about control flow just makes things messy -- I'm very loathe to go
> there just to allow side-effects to be synchronised.

Again, I agree. I see pipelines very much in terms of data flow, and
the order in which steps are executed being driven by a step "needing
data" and pulling it from a previous step.

Orbeon Forms - Web 2.0 Forms for the Enterprise
Received on Thursday, 5 April 2007 04:12:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:42 UTC