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