What is happening is that say for a read operation, the read request is  
noted in the primitive and you return from the primitive then you wait  
on the read semaphore waiting for the semaphore to be signaled, or the  
delay timeout to occur, so your smalltalk process is suspended. So when  
does that process get woken up and run?

At some point if data arrives on the socket, the operating system  
invokes at interrupt time a callback to
some of the macintosh socket code which then does a  
signalSemaphoreWithIndex() in the VM which then requests that  
checkForInterrupts run.

signalSemaphoreWithIndex works with two queues(lists) to prevent race  
conditions (hopefully) from occurring between it's call and the  
checkForInterrupts routine which could be running on another  
CPU/pthread/etc. checkForInterrupts runs about every 3ms on the mac,  
(other platforms like windows I believe trigger it every 1ms).  Lets  
say about 1.5ms of wait time could be in here before the semaphore  
signal is processed.

One of the duties of checkForInterrupts is to check the pending  
interrupts created by signalSemaphoreWithIndex. Those then are sent to  
synchronousSignal, which may depending on the excess signal count takes  
the first process waiting on the semaphore queue and invokes resume:

resume: then takes the process then it either (and here is the  
interesting point) puts the process on the runnable list based on  
priority if the priority of the signaled process is equal to or lower  
than the existing running process, or if the signaled process is higher  
then we switch to the signaled process.

So if the thread is running at (40) UserSchedulingPriority then you get  
to run some time in the future, which could be quite a few ms later,  
since I'd bet Morphs are being updated etc etc.

Now by invoking the thread at highIOPriority you really force the  
resume: logic to transfer control to the block which is waiting on the  
read semaphore. However I'd suggest you use UserInterruptPriority so  
you can do cmd-. if the thread gets away from you because running at  
highIOPriority will prevent you from regain control if the block you  
fork runs away...

Really what you are doing is say that socket i/o should occur before UI  
interaction and display updates, so how much of that do you do?

On Monday, December 9, 2002, at 04:35  AM, jean-marie.zajac wrote:

> I was astonished that "carbon-Mac squeak is slow with ftp primitives"  
> and I have been told that probably results from old Mac API  
> (Opentransport probably) but...  I am now extremely surprised that the  
> ftpSocket speed could be accelerated  by using
> [ ftpSocket primitives ] forkAt: Processor highIOPriority.
> The difference between  processes with highIOPriority and nothing is  
> about  four times ?
> I don't understand how a primitive is more or less rapid. Something  
> gives a priority in a primitive ?
>
> Jean-Marie Zajac
>
>
>
>
--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===