>	client nextPutAll: (String new: 100000). "<- This will block!"
> ... and your Squeak stands forever. Now where is the whole point here?!

(Chuckle).  Andreas, you beat me to it by a few hours --- I'm in the wrong
timezone for this discussion.

Having written custom multi-threaded servers in C, C++, Prolog [try it
sometime!] and Smalltalk, usually with each ported to MacTCP, Win16, Win32,
and multiple UNIX flavours, I much prefer to make use of non-blocking
sockets that take what they can on a request, and give what they can on a
request.  In the case of Squeak, I then use image-level threads (Processes)
to build up the appearance of a byte stream where you can wait for a fixed
number of bytes.

I also find it's important to find out how each platform can notify you of
changes in host socket state: signals plus non-blocking select() calls work
well on UNIX, and Windows can be persuaded (with the aid of a large mallet)
to post events to the thread event queue.  MacTCP I just have to live with
(tho' it's a good few years since I tried, and it may well have changed for
the better).  This gives asynchronous notification of events, usually
including disconnects and other 'hard-to-detect' events.  It may be hard to
demultiplex the notifications into a useful form within the VM, but it's not
impossible.

I support re-factoring the Squeak network support, but I'd do this so that
the asynchronous notification was brought directly into the image with fast
primitive queries for socket state.  A single *barrier* (think semaphore
that releases all waiters on a single signal) plus a primitive that returns
a bitmask of ready states for the socket (writable, data waiting, connected,
half-closed etc) would be my ideal for fast, reliable, and above all *easy*
server-side coding.  I know it can be done relatively simply on UNIX,
suspect it can on WinSock 2.0, and have spent too many years away from the
subject to know anything about the network support on other OSs ---
especially palmtops.

This all also works well with pre-emptive scheduling in the image, otherwise
one Process can lock out others for an arbitrary period, which wrecks
response times.  I had that with VW; haven't re-implemented it in Squeak
yet.

Just my 0.02 Euro.

		- Peter