From: "Tanaka Akira" <akr / m17n.org>
>
> In article <00f801c5aeb2$df9c47a0$6442a8c0@musicbox>,
>   "Bill Kelly" <billk / cts.com> writes:
> 
> > Right... For the program I'm writing right now, if I were
> > using threads, what I'd like is to have is multiple
> > pairs of threads--a read thread doing
> >
> >   sock.gets()
> >
> > and a write thread doing
> >
> >   sock.puts(line)
> >
> > ... but I'm afraid the #puts will block my whole process,
> > potentially. . . . So I can break that down into select()
> > and send() with NONBLOCK ... But then I'm afraid to use
> > puts() on the same socket, because I fear mixing high-level
> > gets/puts with low-level send/recv...  So I presume I need
> > to break both threads into select() and send/recv...
> 
> I can understand the fear.  However I'm not sure how it can be
> eliminated.  Some documenatation might help.

Wow, I guess I did say "afraid" a lot of times there.

As I mentioned earlier, I'm still experimenting with
multi-threaded and single-threaded-select() based 
implementations.

I wrote a new single-threaded-select() implementation, but
it *was* a lot more code than a threaded version using Queue
would have been.  So this afternoon I put the single-threaded
version aside, and coded up a multi-threaded version, using
gets / puts as I described above.

The multi-threaded version looks nice, but here's what
I'm getting on Windows:

>> require 'socket'
=> true
>> require 'thread'
=> true
>> sv = TCPServer.new(12345)
=> #<TCPServer:0x2dbbc90>
>> cl = TCPSocket.new("localhost", 12345)
=> #<TCPSocket:0x2db8e28>
>> th1 = Thread.new {  sleep(1.0) until cl.eof?  }
=> #<Thread:0x2db4c70 sleep>
>> th2 = Thread.new {  sleep(1.0) until cl.eof?  }
=> #<Thread:0x2db0a58 sleep>
>> cl.eof?

   ^^^^^^^^  This call never returns, the whole process hangs,
apparently.

This is ruby 1.8.2 (2004-12-25) [i386-mswin32]

I must admit I didn't expect it to block the process in this
situation.  Am I doing something stupid?

... Hmmm, I'm getting this same hanging behavior in Linux,
regardless of whether the socket is in O_NONBLOCK mode.

Hrm.. It appears this is hanging due to the TCPServer being
in the same Ruby process as the client.

Or at least it seemed to make a difference on Linux... But
on Windows, even with the server socket being created in
a separate process, I'm still getting:

>> require 'socket'
=> true
>> require 'thread'
=> true
>> cl = TCPSocket.new("localhost", 12345)
=> #<TCPSocket:0x2dbaf88>
>> th1 = Thread.new {  sleep(1.0) until cl.eof?  }
=> #<Thread:0x2db6dd0 sleep>
>> th2 = Thread.new {  sleep(1.0) until cl.eof?  }
=> #<Thread:0x2db2bb8 sleep>
>> cl.eof?

   ^^^^^^^^ hang


Am I doing something dumb here?  It seems this should be
legal.


Thanks,

Regards,

Bill