- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Wed, 04 Apr 2007 20:24:09 +0100
- To: public-xml-processing-model-wg <public-xml-processing-model-wg@w3.org>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. What follows from this is that if you have an out-of-band dependency, you _must_ either synchronise it oob, or use the writing of outputs and the reading of inputs to do so. So, that ends up being another argument against explicit step-on-step dependency annotations: that would require my imaginery implementation to add an explicit thread management layer, where before the normal mechanisms of blocking for input would have done the job without any explicit control flow management at all. 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. ht - -- Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh Half-time member of W3C Team 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk URL: http://www.ltg.ed.ac.uk/~ht/ [mail really from me _always_ has this .sig -- mail without it is forged spam] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFGE/tZkjnJixAXWBoRAsgmAJ9sky0HXOY5p141EqiJCEZM9Lky0ACfZmi4 mt8JL1J9V+UCQ5JBM8DKN/c= =LTw9 -----END PGP SIGNATURE-----
Received on Wednesday, 4 April 2007 19:24:18 UTC