[squeak-dev] Re: Bug whith contextOn:do:

Eliot Miranda eliot.miranda at gmail.com
Tue Apr 7 16:57:45 UTC 2015


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 at freudenbergs.de>
wrote:

> On 01.04.2015, at 20:51, Eliot Miranda <eliot.miranda at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150407/e838e0e8/attachment.htm


More information about the Squeak-dev mailing list