Block reading from socket and STDIN

Hi I am pretty new in ruby, may be this topic has already been discussed
here. But I start running out of resources.
I am on a Windows XP PC and I am using ruby186-26.

I am writing a client/Multiplexing Server socket application,
(I took most of the code from the manual).

The server application, beside to listening on the socket via the
select(...), must listening at the standard input. This is because a
user has to give input to the server while he is handling the socket
connection to clients.

The problem I found is that the select(...) and the STDIN.gets methos
are both blocking also if I run it on two different threads.

Many thanks

···

--
Posted via http://www.ruby-forum.com/.

This is off the top of my head, so apologies if it's wrong, but as STDIN is a regular IO object you _should_ be able to handle its input from the same select(...) call as the server socket.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net

···

On 26 Feb 2009, at 09:32, Giuseppe Parlavecchio wrote:

Hi I am pretty new in ruby, may be this topic has already been discussed
here. But I start running out of resources.
I am on a Windows XP PC and I am using ruby186-26.

I am writing a client/Multiplexing Server socket application,
(I took most of the code from the manual).

The server application, beside to listening on the socket via the
select(...), must listening at the standard input. This is because a
user has to give input to the server while he is handling the socket
connection to clients.

The problem I found is that the select(...) and the STDIN.gets methos
are both blocking also if I run it on two different threads.

----
raise ArgumentError unless @reality.responds_to? :reason

Giuseppe Parlavecchio wrote:

Hi I am pretty new in ruby, may be this topic has already been discussed
here. But I start running out of resources.
I am on a Windows XP PC and I am using ruby186-26.

I am writing a client/Multiplexing Server socket application,
(I took most of the code from the manual).

The server application, beside to listening on the socket via the
select(...), must listening at the standard input. This is because a
user has to give input to the server while he is handling the socket
connection to clients.

The problem I found is that the select(...) and the STDIN.gets methos
are both blocking also if I run it on two different threads.

Many thanks

Windows + STDIN.gets == ruby blocks other threads, sorry to say.

At least, that's my experience in ruby186. Maybe this has changed more recently?

···

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

Pretty sure gets doesn't actually block. I believe it is implemented with a
select internally.

Try this as a test
Thread.new {
  loop {
    puts "loop "
  }
}
STDIN.gets

If it stops then gets is blocking

···

On Thu, Feb 26, 2009 at 8:01 PM, Eleanor McHugh < eleanor@games-with-brains.com> wrote:

On 26 Feb 2009, at 09:32, Giuseppe Parlavecchio wrote:

Hi I am pretty new in ruby, may be this topic has already been discussed
here. But I start running out of resources.
I am on a Windows XP PC and I am using ruby186-26.

I am writing a client/Multiplexing Server socket application,
(I took most of the code from the manual).

The server application, beside to listening on the socket via the
select(...), must listening at the standard input. This is because a
user has to give input to the server while he is handling the socket
connection to clients.

The problem I found is that the select(...) and the STDIN.gets methos
are both blocking also if I run it on two different threads.

This is off the top of my head, so apologies if it's wrong, but as STDIN is
a regular IO object you _should_ be able to handle its input from the same
select(...) call as the server socket.

Ellie

Eleanor McHugh
Games With Brains
http://slides.games-with-brains.net
----
raise ArgumentError unless @reality.responds_to? :reason

--
The UNIX system has a command, nice ... in order to be nice to the other
users. Nobody ever uses it." - Andrew S. Tanenbaum