Anyone got a fire-bucket to hand?  The flames are starting to get higher...
and I'm unsure whether this mail will douse a few or ignite more.

[...]
>> client nextPutAll: (String new: 100000). "<- This will block!"
>> ...and your Squeak stands forever. 
[...]
> The current Squeak support will go into an endless loop (in a Smalltalk
process, from which one may halt) if you evaluate the last line twice. [...]

What this says to me is that the Correspondents framework needs a
fix/workaround for this problem, and that the current networking support has
a workaround that has the undesirable side-effect of causing a tight loop in
the image.

Maybe, instead of each proponent denouncing the other, both would be better
occupied collaborating to find a networking framework that avoids these
problems?

[reordering by PJC]
> That's not a useful example; in real life data is consumed, not just
written.
> I have a workaround if you truly think that example is compelling.

I think it's compelling.  Imagine serving a large GIF to a stalled copy of
Internet Explorer 3 16-bit.  It happens all too frequently, and the server
ought not to stall in this case --- either by blocking, or by screaming
round a tight write loop.

[more reordering]
> On the other hand, I've never encountered this case in thirteen years of
network programming, so I'd have no problem just ignoring it.
> select() on win32 is broken
> I hate to play the "it's a Microsoft bug" card here (almost as much as I
hate the bug :), but it does seem to be the problem.

Here's a good reason for using asynchronous notification from the host OS.
As an aside, I'd note that it's never entirely wise to trust MS
documentation or one's own experience when dealing with MS WinSock, or
indeed the entire MS TCP/IP stack, as I found out (and posted) about last
March.

I would most certainly have a problem with using any networking framework
where the implementors decided to ignore a known bug simply because they
hadn't encountered it before... it reminds me rather of the hospital
electrician who installed 10base2 cabling with 5mm bend radii, because
that's what he'd always done with mains cable.  When told it wouldn't work
by a network consultant, he laughed in the consultant's face, said 'I've
been working with electricity for twenty years, and you can't tell me that
there's one kind of electricity that goes round corners and another that
doesn't', and carried on exactly as before.

> The socket wasn't ready for writing, so the blocking select() shouldn't
have returned.

Did it set any errno?  There are a number of situations in which the
(emulated, IIRC) WinSock select() will return early.  Ditto the UNIX
select().

> Please don't speak (write) to me that way.

Pot.  Kettle.  Whatever.

		- Peter