On 22/10/2007, Klaus D. Witzel klaus.witzel@cobss.com wrote:
Not only slow-down :( For an example, have a look at the implementor of #debug:title:full: in class Process, where thisContext is assigned to a variable.
When #ifTrue:ifFalse: is really sent, ([thisContext] class) is BlockContext *and* its sender is nil so the test for #hasContext: in the next statement fails.
I think this is because of optimization. For BlockContext a sender should be a context of method #ifTrue:ifFalse: (which sends #value to block). But compiler never creates such context due to optimization. In this case, since compiler 'cuts' the #ifTrue:ifFalse: out, then a correct context, i think, should be a sender of #ifTrue:ifFalse?? but not nil.
But Squeak's compiler [usually] doesn't emit code for sending #ifTrue:ifFalse: so ([thisContext] class) is MethodContext and #hasContext: doesn't fail (in this example).
Then the only way how we could regain this loss is to use highly parallelisable algorithms.
... which can be employed regardless of 'erlangenization' :)
A trivial code comes in mind:
(1 to: 1000) do: [:i | [ aBlock value:i ] fork ]
but this leads to burden our parallel processes with scheduling. I would like, instead, to be able to run a number of parallel branches for same process (to schedule a process instead each of these branches).
(1 to: 1000) doInParallel: [:i | aBlock value ]
I really don't like adding another abstraction like Thread, in addition to Process. Maybe we should stick with a Process and have a subclass of it, like ProcessNoScheduling. I'm just thinking, in what ways we can avoid excessive scheduling/preempting? Or maybe, by following road of 'erlangisation' we should make a Process more lightweight, so spawning thousands of them will not cause a speed degradation.