In article <033601c5a9fa$26ba7840$6442a8c0@musicbox>,
  "Bill Kelly" <billk / cts.com> writes:

> Wow - the main thing holding back progress on this front is
> method names?  I could embrace connect_nonblock or nbconnect,
> there.

Do you have a problem with threads?

If you use threads, nonblocking methods are not required in general.

I'd like to know why people doesn't use threads.

> The blocking I/O issues are the thorniest problem for me
> writing applications in ruby.  (Of course, it's 1000 times
> worse on Windows, ... where nonblocking I/O is apparently not
> supported at all yet.  That is just a nightmare.)

I heard Windows has nonblocking I/O for sockets.

> But regarding the method names - I'm wondering - are separate
> methods really needed?  Are there any cases where Ruby can't
> just inspect the fcntl() flags of the socket, and if 
> O_NONBLOCK is set, provide nonblocking behavior?  You mentioned
> connect(), which is an instance method.  Couldn't connect() 
> just check for O_NONBLOCK?  Why would a separate method be
> needed?   (Sorry if this is a FAQ.  :)

1. The threaded programs needs blocking methods for a IO object with
  O_NONBLOCK.  O_NONBLOCK is required to avoid enteire process
  blocking by write operations.  But the threaded programs still
  needs blocking behavior because most threaded programs doesn't
  expects EAGAIN.  I think nonblocking methods are better than
  implementing EAGAIN retry loop for all threaded programs.

2. There is no F_GETFL on Windows.
  Ruby cannot test O_NONBLOCK is set/clear on a fd.  So connect
  method cannot check O_NONBLOCK.
-- 
Tanaka Akira