<div dir="ltr">Hi Chris,<div><br></div><div>   forgive my pedantry, but this is important.</div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 27, 2017 at 11:35 AM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="gmail-">>> >> A single process to write and another to read, both at same priority<br>
>> >> so only one can be  doing stuff at once.<br>
>> ><br>
>> > Mmmm, those two will not preempt each other - but other processes with<br>
>> > higher prio preempt them (right?), so perhaps I am daft but doesn't that<br>
>> > mean they will switch anyway (potentially in the middle of a method etc)?<br>
<br>
</span>In essence, they do preempt each other.  They will not preempt each<br>
other when they are blasting bytes over the network, but as soon as<br>
the net buffer fills up due to waiting for data transmission in either<br>
the send or the receive, the other one, if data is available, will<br>
take off.<br></blockquote><div><br></div><div>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.  </div><div><br></div><div>So to the question: "doesn't that mean they will switch anyway (potentially in the middle of a method etc)?"</div><div><br></div><div>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.</div><div><br></div><div>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 <span style="color:rgb(0,0,0);font-size:12.800000190734863px">SmalltalkImage current processPreemptionYields = false  </span><font color="#000000"><span style="font-size:12.800000190734863px">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.  </span></font></div><div><font color="#000000"><span style="font-size:12.800000190734863px"><br></span></font></div><div><font color="#000000"><span style="font-size:12.800000190734863px">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.</span></font></div><div><font color="#000000"><span style="font-size:12.800000190734863px"><br></span></font></div><div><font color="#000000"><span style="font-size:12.800000190734863px">Hope this clarifies things.</span></font></div></div><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>