Hi Bert,

sorry. Got deep into something and have only just come up for air...

On Thu, Apr 2, 2015 at 1:02 AM, Bert Freudenberg <bert@freudenbergs.de> wrote:

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?

That depends. If the VM is /not/ in the processPreemptionYields regime (and I need to remember to put Spur images into this regime) then no, doing the fork at a higher priority cannot disturb processes. But if the process is forked at the same priority, or if the VM is in the processPreemptionYields regime, then yes, this can screw up process priorities.

So assuming

Smalltalk processPreemptionYields: false

then the following is, I think, safe:

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

of course this fails at max priority. Since we don't use the max priority we can get away with this. I think that's more acceptable than getting away with occasionally popping the receiver off a context's stack, no? If that's not acceptable we need a primitive.

- Bert -

best,

Eliot