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

> On 16-02-2017, at 3:54 AM, Göran Krampe <goran@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@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