Digest Articles 181864-182030 (17/17) (ruby-talk ML)

I'm somewhat new to Ruby and have been playing around with some very simple
socket code (starting the script and then telnetting to the box on the port
specified). I wanted to allow it to accept more than one request at a time
so I added some threads. However, now that I've added some thread code, I
can't get the script to end properly (I guess "as expected" is more
appropriate). Here's some code:

Ok, before I talk about your code, you may like to know that you don't actually need to use threads to handle multiple sockets at once. There is a method in the kernel called "select" that can be used thus:

require 'socket'

server = TCPServer.new(5000)
sockets =

while( server )
  # Wait for read events on the server or sockets.
  socketsWithEvents = select( [server] + sockets )[0]

  # Process each socket that has an event.
  socketsWithEvents.each do |soc|
    if soc == server
      sockets << soc.accept
    else
      # Close the socket if the other end has closed.
      if soc.eof?
        soc.close
        sockets.delete(soc)
        break
      end

      s = soc.gets.chomp
      soc.puts "You said \"#{s}\", you land lubber!"
      server=nil if s=="close"
    end
  end
end

You should be able to begin as many concurrent telnet sessions to port 5000 as you wish, and anything typed on any will be pirated back at.

... Perhaps other more knowledgeable Ruby users could comment on the advantages or disadvantages of using threads or avoiding them.

As a top tip, I'd heartily recommend (if you don't already) playing about with "irb", and trying out sockets "hands on". It's brilliant to be able to write TCPServer.new(5000).accept, and wait for it to return a new connection :slight_smile:

require 'socket'
p = 3333
threads =
s = ''

server = TCPServer.new('0.0.0.0', p)

while (session = server.accept)
  threads << Thread.new(session) do |ts|
    ts.print "What's your name?\r\n"
    puts "Request: #{s = ts.gets.chomp!}"
    ts.print "\r\nHello #{s}, thanks for stopping by\r\n\r\n"
    ts.close
  end
  break if s == 'close'
end

I've just read someone else's reply mentioning that you have a "race condition". What's happening is that when you create the thread, you've got two lines of execution that are "racing" along through your code, and you can never really know which one is going to be in the lead ay any moment...

Thread.new builds a new thread that runs the block you passed in. This thread is handling the newly created socket.

The original thread instantly returns from the Thread.new, and starts processing just after the block on the line "break if s == 'close'".

If you're not familiar with threads, it's almost as if you've suddenly got two processors instead of one - both of them are dashing through your code executing statements happily, which is why careless thread programming can cause merry havoc :slight_smile:

Generally, you can't make guarantees about the speed that the two threads will progress through the code they're assigned to. One may go slowly for a while, and then very fast. If you need one thread to hang back (the main thread, in this case) while the other does something (the socket's thread does the read and sets the variable "s"), then you _must_ use synchronisation mechanisms (Look up "monitors" for starters).

In your case, the original thread will (usually) evaluate the "break if..." line almost instantly, long before the new thread even gets a chance to write to the thread, let alone read from it in to "s". When the original thread checks "s", it wont have been updated to by the newly spawned thread, so you wont execute the conditional break (until the next time through the loop).

HTH, cheers (and have fun :slight_smile:
  Benjohn

I'm somewhat new to Ruby and have been playing around with some very simple
socket code (starting the script and then telnetting to the box on the port
specified). I wanted to allow it to accept more than one request at a time
so I added some threads. However, now that I've added some thread code, I
can't get the script to end properly (I guess "as expected" is more
appropriate). Here's some code:

Ok, before I talk about your code, you may like to know that you don't actually need to use threads to handle multiple sockets at once. There is a method in the kernel called "select" that can be used thus:

require 'socket'

server = TCPServer.new(5000)
sockets =

while( server )
  # Wait for read events on the server or sockets.
  socketsWithEvents = select( [server] + sockets )[0]

  # Process each socket that has an event.
  socketsWithEvents.each do |soc|
    if soc == server
      sockets << soc.accept
    else
      # Close the socket if the other end has closed.
      if soc.eof?
        soc.close
        sockets.delete(soc)
        break
      end

      s = soc.gets.chomp
      soc.puts "You said \"#{s}\", you land lubber!"
      server=nil if s=="close"
    end
  end
end

You should be able to begin as many concurrent telnet sessions to port 5000 as you wish, and anything typed on any will be pirated back at.

... Perhaps other more knowledgeable Ruby users could comment on the advantages or disadvantages of using threads or avoiding them.

As a top tip, I'd heartily recommend (if you don't already) playing about with "irb", and trying out sockets "hands on". It's brilliant to be able to write TCPServer.new(5000).accept, and wait for it to return a new connection :slight_smile:

require 'socket'
p = 3333
threads =
s = ''

server = TCPServer.new('0.0.0.0', p)

while (session = server.accept)
  threads << Thread.new(session) do |ts|
    ts.print "What's your name?\r\n"
    puts "Request: #{s = ts.gets.chomp!}"
    ts.print "\r\nHello #{s}, thanks for stopping by\r\n\r\n"
    ts.close
  end
  break if s == 'close'
end

I've just read someone else's reply mentioning that you have a "race condition". What's happening is that when you create the thread, you've got two lines of execution that are "racing" along through your code, and you can never really know which one is going to be in the lead ay any moment...

Thread.new builds a new thread that runs the block you passed in. This thread is handling the newly created socket.

The original thread instantly returns from the Thread.new, and starts processing just after the block on the line "break if s == 'close'".

If you're not familiar with threads, it's almost as if you've suddenly got two processors instead of one - both of them are dashing through your code executing statements happily, which is why careless thread programming can cause merry havoc :slight_smile:

Generally, you can't make guarantees about the speed that the two threads will progress through the code they're assigned to. One may go slowly for a while, and then very fast. If you need one thread to hang back (the main thread, in this case) while the other does something (the socket's thread does the read and sets the variable "s"), then you _must_ use synchronisation mechanisms (Look up "monitors" for starters).

In your case, the original thread will (usually) evaluate the "break if..." line almost instantly, long before the new thread even gets a chance to write to the thread, let alone read from it in to "s". When the original thread checks "s", it wont have been updated to by the newly spawned thread, so you wont execute the conditional break (until the next time through the loop).

HTH, cheers (and have fun :slight_smile:
  Benjohn

:frowning: Sorry about the digest subject of that last post.

I think you meant to say "parroted back" instead of "pirated back",
although it's pretty funny since pirates are often assumed to own
parrots.

ยทยทยท

On 3/2/06, Benjohn Barnes <benjohn@fysh.org> wrote:

You should be able to begin as many concurrent telnet sessions to
port 5000 as you wish, and anything typed on any will be pirated back
at.

--
R. Mark Volkmann
Partner, Object Computing, Inc.