So this code would never be executed from the timer event loop that runs at
priority 80?
Recently I tried profiling the timer event loop and the profiler wanted to
run at +1 priority and failed.
cheers -ben

On Wed, Apr 8, 2015 at 12:57 AM, Eliot Miranda <eliot.miranda at gmail.com>
wrote:

> 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/20150408/f7cfcd0e/attachment-0001.htm