[Vm-dev] Re: [squeak-dev] Re: Socket>>#sendData:count: does no error checking and hence locks up the system

Eliot Miranda eliot.miranda at gmail.com
Tue Mar 1 21:20:42 UTC 2016

On Tue, Mar 1, 2016 at 12:32 PM, Bert Freudenberg <bert at freudenbergs.de>

> On 01.03.2016, at 21:14, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> > Hi All,
> >
> >     one thing this lock-up suggests is that interrupting should
> interrupt all processes running at user priority, not just the uiProcess.
> Does that make sense?  It does to me, but would be something I'd control by
> a preference for testing its effects.
> I thought it interrupted the active process? Wouldn’t that make most sense?

Not necessarily.  For example, in the test I referred to, testSocketReuse,
the ui process (the process running the test) spawns two other processes
that spin hard, one trying to write to a socket and one trying to read form
a socket.  If the socket code doesn't detect errors properly then these
processes continue to spin hard.  If one interrupts then /nothing/ appears
to happen.  The ui process is indeed interrupted, but because the other two
processes continue to spin hard they shut out the notifier which doesn't
appear.  And even if the notifier did appear those processes would still be
spinning hard, making it difficult for the user to interact with the
notifier.  So in this case it makes sense to interrupt all processes
running at user priority.  Arguably it makes sense to interrupt any and all
processes running at or above user priority and below user interrupt
priority.  Usually there's only the ui process in this range, but
occasionally there are more and errors can cause them to make an interrupt
ineffective if it only interrupts the ui process.

> - Bert -

best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160301/49cf212d/attachment-0001.htm

More information about the Vm-dev mailing list