Re: XProc execution model

Thank you Henry. Everything you say makes sense.

Just one addition: I would argue that the perspective of the user is more
important than the perspective of the implementer. The user of a
(high-level) language expects the compiler and/or runtime to do certain
optimizations. He wants his pipeline to be executed as efficiently as
possible. Attributes such as the one I proposed can help with doing those
optimizations.

You gave the example of an implementation strategy that makes use of
multi-threading to let the order of execution be automatically determined.
It isn't hard to come up with a variant of this strategy that, instead of
waiting for input to arrive and then eagerly get to work, waits until
output is actually requested before doing anything. This would also reduce
the size of the buffers needed.

Thanks,
Bert


Op za 30 mei 2020 om 00:27 schreef Henry S. Thompson <ht@inf.ed.ac.uk>:

> A minor note:  The key thing about the architecture, from my perspective
> as a (former) implementer and (occasional) user is that neither party
> has to understand (or can depend) on the order in which anything
> happens.  In particular, it's _perfectly_ OK as an implementation
> strategy to simply start _every_ step instance in the pipeline(s)
> running, in whatever order you and the underlying thread / processor
> implementation find convenient, and everything will be just fine.
> Almost all of them will block waiting for input, and wake up and get to
> work when and only when there is any real work to do.
>
> There's also a minor consequence of this which actually simplifies step
> implementation: _nothing_ in step instance initialisation can assume
> that _any_ other step instance has been initialised before it.
>