When people say "poll" from the image, are they talking about things
like "self dataAvailable" and "self isConnected"?  Well, how slow can
such checks possibly be, especially if the VM can answer such requests
without doing a system call?  I'd wager they could be tuned up to be
pretty darned fast if you try.  And it seems like you can't avoid some
of them no matter what you do--for instance, it's critical to keep
verifying that the socket is still connected before you try anything
else.


Lex




> 
> On our project (at Advantive), we have re-written the Socket interface
code
> on the WinNT platform.  We've done it in a pluggable primitive fashion
and
> called it XSockets (for the moment).  This allows us to use both the
old
> socket code and XSockets simultaneously.
> 
> What we did in a nutshell is eliminate polling in the VM, made use of
NT's
> overlapped I/O and I/O completion ports to avoid unnecessary creation
of
> threads (using only one thread per CPU).  Each IO call is passed a
unique
> external Semaphore to signal completion and a handle to an IO object
is
> answered by the primitive.  After the semaphore is signaled, the IO
object
> can be queried for results of the call.  It works very nice, it makes
the
> code cleaner, and I *think* it is more scalable (we'll soon find out).
 We
> have not yet added an ability to connect these XSockets (only works
for
> accepting incoming connections).
> 
> Thus, our two primary classes are:
> 
> XSocket, and
> XSocketIO
> 
> We plan to use a similar scheme for asynchronous file IO as well.  So
far
> the performance and reliability is very good.
> 
> The following is XSocket>>getData (to provide an illustration):
> 
> ----
> getData
> 	| buf io |
> 	"Get some data"
> 
> 	io _ XSocketIO new.
> 	io ioHandle: (self
> 		primSocket: socketHandle
> 		receiveBufSize: 2000
> 		sema: io semaIndex).
> 	io ioHandle isNull ifTrue: [ ^self error: 'IO failed' ].
> 
> 	io waitOnIO.
> 	buf _ io ioBuffer.
> 	io destroy. "Finalization will also do this for us."
> 	^buf
> ----