On 24 Jun 2009, at 12:02, Stian Soiland-Reyes wrote: > On Mon, Jun 22, 2009 at 13:47, Jan Hidders<[email protected]> > wrote: > >> It's probably not even true that these >> streams should start and stop at the same moment, nor do they need to >> have the same length. What I mean is: this is not a rule that holds >> in >> general. I understand that in many cases this holds, but this is then >> due to the semantics of the activities in the list of activities >> associated with the processor, rather than that the processor >> enforces >> this. Correct? > > Well, they would have to be of the same length, but it's not currently > enforced. (enforcing this would mean to keep additional state). The > reason is that if you've 'finished' output on port A, then you can't > really continue outputting on port B, because you would be returning > [1,3,4] b={"fish"} - what is the value of a for position [1,3,4] ? > > To support this the activity would have to be able to return values > with individual indexes, something like: > > { a[1,2,3] = "fish", > b[1,2] = "soup" } > > This is not currently supported in the API, but it might be something > we could possibly add if there comes a case of activities that need to > do that.
That's exactly how we now formally describe the output of activities, because that allows us to describe both streaming and non-streaming output of an activity. The latter is just a special case where all the output events happen more or less at the same time. So that is where my question came from. If you have an activity with output streams and two output ports, say 'a' and 'b', and its output is a = ["x","y"] and b = ["z"], then this could arrive as for example a[1] = "x" ; b[1] = "z" ; a[2] = "y" ; a[] = ["x", "y"] So that there is an a[2] event does not mean that there also has to be an b[2] event. That's what I meant with "they don't have to be of the same length". Btw. in the formal semantics we assume that nested workflows also have such streaming outputs that might already be forwarded before the values have completely arrived. That the real implementation doesn't allow this yet (I suspect this) is not per se a problem because it would still implement one of the possible behaviors described by the formal semantics. >> The only thing that the processor would enforce is that every >> iteration has completely stopped once it has sent its last output >> message. > > No - as the activity thread has an asynchronous callback, it can't > really know that the activity invocation thread has 'stopped' - it > does not enforce this - and it probably should not - perhaps the > activity needs to do some clean-up after returning its values. Ok. That in fact simplifies our task somewhat. -- Jan Hidders ------------------------------------------------------------------------------ _______________________________________________ taverna-hackers mailing list [email protected] Web site: http://www.taverna.org.uk Mailing lists: http://www.taverna.org.uk/taverna-mailing-lists/ Developers Guide: http://www.mygrid.org.uk/tools/developer-information
