On 22/10/2007, Klaus D. Witzel <klaus.witzel at 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.


-- 
Best regards,
Igor Stasenko AKA sig.