[squeak-dev] Resuming a SocketStream after a ConnectionClosed exception?

Eliot Miranda eliot.miranda at gmail.com
Mon Feb 27 20:30:29 UTC 2017


Hi Chris,

   forgive my pedantry, but this is important.

On Mon, Feb 27, 2017 at 11:35 AM, Chris Muller <asqueaker at gmail.com> wrote:

> >> >> A single process to write and another to read, both at same priority
> >> >> so only one can be  doing stuff at once.
> >> >
> >> > Mmmm, those two will not preempt each other - but other processes with
> >> > higher prio preempt them (right?), so perhaps I am daft but doesn't
> that
> >> > mean they will switch anyway (potentially in the middle of a method
> etc)?
>
> In essence, they do preempt each other.  They will not preempt each
> other when they are blasting bytes over the network, but as soon as
> the net buffer fills up due to waiting for data transmission in either
> the send or the receive, the other one, if data is available, will
> take off.
>

No they will *not* preempt each other.  Preemption means an arbitrary
suspension of the preempted thread by another thread.  It does /not/ mean a
thread blocking and hence yielding to another thread.  So what will happen
with the two threads reading and writing sockets is that they will only
suspend when they wait on some semaphore that is to be signalled when some
activity (e.g. reading or writing) is complete.  And these suspension
points are (if properly written) safe points.

So to the question: "doesn't that mean they will switch anyway (potentially
in the middle of a method etc)?"

With the standard Smalltalk-80 scheduler, yes.  Any preemption by a higher
priority process put the preempted process to the back of its run queue,
hence causing the next process at that priority to also preempt the
preempted process.  This destroys cooperative multi-threading.

But the current Cog scheduler does /not/ put a process to the back of its
run queue provided it is in the right mode (see SmalltalkImage current
processPreemptionYields = false  and ProcessorScheduler class>>#startUp: as
mentioned elsewhere). In this mode the lower-priority process gets
preempted by the higher-priority process, but remains at the head of the
run queue at its priority and so as soon as the higher priority process
blocks the lower priority process will resume where it left off.

So the new scheduler mode (a mode that's been in the VisualWorks scheduler
by default for many decades) preserves cooperative scheduling amongst
processes of the same priority.  It /does/ prevent processes at the same
priority from preempting each other.

Hope this clarifies things.
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170227/e803a94c/attachment.html>


More information about the Squeak-dev mailing list