On 10/22/07, Igor Stasenko <siguctua at gmail.com> wrote:
>
> Yes, a simple example when i need to have correct order:
> Collection>>do:

Well, first of all, do you want do to be parallel?  I would personally
prefer to have a #parallelDo: for that.  Second of all, the point of
having the multiple processes is that we can run these things in
parallel in different threads and different processes.  How do you
suggest controlling execution order in that scenario?

If you need work done in parallel and then need the results sorted
back to original order you have to do it in multiple steps, e.g.

1) collect a collection of "things" into a collection of associations
that have "thing" keys and position as the value,
2) run the parralelDo on this new collection
3) take the results and collect them back into the correct order using the value

or you could do something like this: http://bc.tech.coop/blog/070520.html

> So, we need at least 2 messages to reflect a different behaviour:
> #do:
> and
> #orderedDo:
>
> and that's only the simplest case...

How do you envision this working?  It's no better using
shared-state/fine-grained locking unless you are modifying the
collection in place, which do and co. are not doing now.