On 2 December 2017 at 02:00, Eliot Miranda <eliot.miranda at gmail.com> wrote:

> Hi Nicolas,
>
> On Thu, Nov 30, 2017 at 6:18 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>>
>>
>> 2017-12-01 3:07 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
>>
>>> Hi Nicolas,
>>>
>>> On Thu, Nov 30, 2017 at 5:55 PM, Nicolas Cellier <
>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>
>>>> I just had a great success in interrupting a critical: block... Is this
>>>> possibility expected?
>>>>
>>>
>>> Yes.  Interrupts are orthogonal to critical sections, including
>>> critical: blocks.  The only thing a critical: does is arrange that only one
>>> process can be executing it at any one time.  If you want
>>> uninterruptibility you'll want to use valueUninterruptibility.
>>>
>>>
>> thanks, I was indeed confusing
>>
>> Too bad, the UI is now completely blocked...
>>>>
>>>
>>> (have you tried user interrupt again?)
>>>
>>>
>>
>> yes without success.
>>
>> So the real issue is what process the user interrupt action should
>>> interrupt.  For example, I think it's very wrong that the user interrupt
>>> action can interrupt the finalization process.  But which process it
>>> chooses is not well defined.  We've discussed this in the past without
>>> coming to much of a conclusion.
>>>
>>>
>> Without any consideration about implementation, maybe we could base
>> user-interruptability on the Process priority and pray for never forking a
>> runaway high priority.
>>
>
> I agree.  For me the choice of processes and priorities is clear.  Any
> runnable process in the range
>     Processor userBackgroundPriority to: Processor userInterruptPriority -
> 1
> is a candidate for interruption.  One question is whether to interrupt the
> currently active one or all processes in that range.  That could be
> answered by a preference, or simply based on our existing experience,
> interrupting the highest priority currently running (at the head of its run
> queue) process in that range.
>

How feasible is it for a heuristic to consider things like...
* % load
* stack depth
* blocked on semaphore

Perhaps a performance monitoring sample could be taken to gather such data
(i.e. change in stack depth over 100ms)

cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171202/e40a7ecc/attachment.html>