On Thu, Feb 16, 2017 at 10:06 AM, tim Rowledge <tim at rowledge.org> wrote:

>
> > On 16-02-2017, at 3:54 AM, Göran Krampe <goran at krampe.se> wrote:
> >
> > On 15/02/17 22:34, tim Rowledge wrote:
> >> Hi Göran!
> >>
> >>> On 15-02-2017, at 3:50 AM, Göran Krampe <goran at krampe.se> wrote:
> >>>
> >>
> >>> I wrote the current incarnation of SocketStream and I intentionally
> >>> did not add any semaphore/mutex for protections. And yes, the
> >>> SocketStream has internal state to know positions in buffers etc
> >>> etc - so NO, you should not use two Processes with the same
> >>> SocketStream.
> >>>
> >>> Having said that...  if you have one process only writing and one
> >>> only reading - you may get away with it - IIRC (no promises) the
> >>> inBuffer and outBuffer (and associated ivars) may be 100%
> >>> separated.
> >>
> >> 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)?
>
> If I’ve remembered right, the scheduling sticks a suspended process at at
> the *front* of the queue these days, not the back as was the case when us
> dinosaurs first roamed the Earth. The idea being to make sure that a
> process interrupted by a quick timer job gets back to its work sooner
> rather than later.
>

That is indeed the case.  See

    SmalltalkImage current processPreemptionYields = false

and ProcessorScheduler class>>#startUp:

_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20170225/6e97b824/attachment.html>