Ian,

Read slowly:

On 4 Jan 2008, at 17:34, ian / frogcottage.demon.co.uk wrote:

> On 4 Jan, 15:35, James Tucker <jftuc... / gmail.com> wrote:
>> On 4 Jan 2008, at 11:14, Francis Cianfrocca wrote:
>>> On Jan 4, 2008 10:01 AM, James Tucker <jftuc... / gmail.com> wrote:
>>
>>>> STDIN.gets blocks hard on windows - that is, it blocks at the "c
>>>> level" which blocks all running green threads.
>>
>>>> The result is this 'lag' behavior - in fact what is happening
>>>> normally
>>>> is that you're not getting any running threads or socket reads  
>>>> except
>>>> in the time between gets returning a value, and being called again.
>>
>>>> If you avoid $stdin, you will find that the flow is smooth.
>>
>>>> Oh, and $stdout blocks too...
>>
>>>> There's a video here that sort of demonstrates this in a visual  
>>>> way:
>>
>>>> http://blog.ra66i.org/wp-content/network_rotator_fun.swf
>>>
>> With or without threads, the problem the OP was describing actually
>> comes up anyway on Windows, as the console IO code could really do
>> with being made non-blocking, like it is on *nix. My understanding is
>> though, that this is non-trivial.
>
> Hi thanks for the answers. I removed the stdin line and replaced it
> with gets, and it still has the same error.

gets *is* $stdin.gets.

> Can I take it Ruby Sockets don't work very well with windows?

Sockets work fine.

Console I/O is where the problem is.

> Big disadvantage if that's true, as it's so often compared to Java,
> and it's claimed that it's multi platform.

I have production (threaded) apps that do not read from $stdin running  
over windows sockets under reasonable load, with no problems  
whatsoever. Ruby has been a great multi-platform solution for us, with  
the same apps running on *nix, Windows and OS X with no platform issues.

> Thanks again, but I'm still non the wiser

Remove your user input altogether, and *generate* the data instead of  
reading it from input, and you will no longer see any issues with the  
'smoothness' of your runtime.

> Ian