On 01.04.2015, at 20:51, Eliot Miranda <eliot.miranda@gmail.com> wrote:

> I would find it very surprising if #jump would result in the execution continuing in a different process.
>
> That's not what they do.  Instead they spawn another process to position the process in which we want to jump correctly.

We don't want to jump to a process but within a process, like a goto…

Well, jump doesn't do unwinds so the code should be simply:

jump
"Abandon thisContext and resume self instead (using the same current process)."
| process |
process := Processor activeProcess.
[process suspendedContext: self] fork.
Processor yield

Ah, I misread what you were proposing before. Simpler is better for understanding :)

Assuming there are more runnable processes at the active priority, could there be a scenario where the #jump context is resumed after the yield, before the forked process had a chance to run? Or would we have to fork it at a higher priority? Could either in any way mess with the order of process activation, which would not happen with the current #jump implementation?

- Bert -