Threading+TCPServer issues on Win32

ruby-talk
1

I'm having an issue with threading and TCP servers on Win32. I've
boiled down the issue to the following code:

···

-----

require 'socket'

t = Thread.new do
  serv = TCPServer.new '', 344
  sock = serv.accept
  sock.puts "ok"
  sock.close
  serv.close
end

puts "OK, enter text: "
puts gets

-----

So with a server listening in the background, the program should
accept one new request and respond with "ok". In the meantime, it
should be waiting for the user to enter text on STDIN.

If this program is running in a UNIX environment, I can telnet to port
344 and I'll be greeted with "ok" and the program will continue to
wait for user input. However, when I run the same code on Windows,
the connection on port 344 opens (i.e. there is no connection refused
error), but no text is received. If I enter a word on the server's
STDIN and hit enter, the server quits and the connection is severed,
but the "ok" still doesn't get to the client.

I am quite possibly missing something obvious here, but I'm not sure
what it is. Any help would be appreciated.

--
Bill Atkins

2

Bill Atkins wrote:

I'm having an issue with threading and TCP servers on Win32. I've
boiled down the issue to the following code:

-----

require 'socket'

t = Thread.new do
  serv = TCPServer.new '', 344
  sock = serv.accept
  sock.puts "ok"
  sock.close
  serv.close
end

puts "OK, enter text: "
puts gets

-----

So with a server listening in the background, the program should
accept one new request and respond with "ok". In the meantime, it
should be waiting for the user to enter text on STDIN.

If this program is running in a UNIX environment, I can telnet to port
344 and I'll be greeted with "ok" and the program will continue to
wait for user input. However, when I run the same code on Windows,
the connection on port 344 opens (i.e. there is no connection refused
error), but no text is received. If I enter a word on the server's
STDIN and hit enter, the server quits and the connection is severed,
but the "ok" still doesn't get to the client.

I am quite possibly missing something obvious here, but I'm not sure
what it is. Any help would be appreciated.

Hi Bill,

that's the same problem as

require 'timeout'
timeout(1){ puts gets }

this will never return (or throw the timeout exception) as
long as you do not hit a key.
Ruby has no native threads, it gets stuck on blocking system
calls.

I tried to circumvent the problem with Kernel#select, but for
some reason

select( [$stdin], nil, nil, 1.5 )

always returns immediately. Is there someone who can explain?

cheers

Simon

3

Simon Kröger wrote:
...

require 'timeout'
timeout(1){ puts gets }

this will never return (or throw the timeout exception) as
long as you do not hit a key.
Ruby has no native threads, it gets stuck on blocking system
calls.

Is this only with a tty, and not a problem with sockets, files, etc.?

···

--
      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

4

Right, I tried select as well, but no dice. Is there some workaround,
aside from splitting off separate processes?

Bill

···

On 8/8/05, Simon Kröger <SimonKroeger@gmx.de> wrote:

Bill Atkins wrote:

> I'm having an issue with threading and TCP servers on Win32. I've
> boiled down the issue to the following code:
>
> -----
>
> require 'socket'
>
> t = Thread.new do
> serv = TCPServer.new '', 344
> sock = serv.accept
> sock.puts "ok"
> sock.close
> serv.close
> end
>
> puts "OK, enter text: "
> puts gets
>
> -----
>
> So with a server listening in the background, the program should
> accept one new request and respond with "ok". In the meantime, it
> should be waiting for the user to enter text on STDIN.
>
> If this program is running in a UNIX environment, I can telnet to port
> 344 and I'll be greeted with "ok" and the program will continue to
> wait for user input. However, when I run the same code on Windows,
> the connection on port 344 opens (i.e. there is no connection refused
> error), but no text is received. If I enter a word on the server's
> STDIN and hit enter, the server quits and the connection is severed,
> but the "ok" still doesn't get to the client.
>
> I am quite possibly missing something obvious here, but I'm not sure
> what it is. Any help would be appreciated.
>

Hi Bill,

that's the same problem as

require 'timeout'
timeout(1){ puts gets }

this will never return (or throw the timeout exception) as
long as you do not hit a key.
Ruby has no native threads, it gets stuck on blocking system
calls.

I tried to circumvent the problem with Kernel#select, but for
some reason

select( [$stdin], nil, nil, 1.5 )

always returns immediately. Is there someone who can explain?

cheers

Simon

--
Bill Atkins

5

that's the same problem as

require 'timeout'
timeout(1){ puts gets }

this will never return (or throw the timeout exception) as
long as you do not hit a key.
Ruby has no native threads, it gets stuck on blocking system
calls.

I tried to circumvent the problem with Kernel#select, but for
some reason

select( [$stdin], nil, nil, 1.5 )

always returns immediately. Is there someone who can explain?

Yes, unfortunately select() on windows only works with
sockets.

I don't know if this will be of any help, but I've used
the following workaround:

if WINDOWS_VERSION
  require 'dl'
  $win32_console_kbhit = Win32API.new("msvcrt", "_kbhit", , 'I')
  def console_input_ready?
    $win32_console_kbhit.call != 0
  end
else
  def console_input_ready?
    select([$stdin], nil, nil, 0) != nil
  end
end

...it's not foolproof. If you do a gets() when
console_input_ready? is true on windows, you'll still block
until the user hits <enter>.

Regards,

Bill

···

From: "Simon Kröger" <SimonKroeger@gmx.de>