On 10/22/07, Igor Stasenko siguctua@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.