In eval.c, select is used to synchronize IO in ruby threads, but on some
platforms select() does not work on non-sockets.  We are told that
Windows is just such a platform.  However, there are no exceptions in
the code to handle the Windows case, which is a bit puzzling.
Apparently, by some accident of the Windows select() implementation,
this doesn't matter, so synchronizing IO in Ruby threads works on
Windows.

In OpenVMS, this assumption that select() can handle non-socket file
descriptors is a big problem[0].  Ruby threads simply won't work.  When
select() is called on a non-socket, an ENOTSOCK error is thrown.  The
thread this happens to is now no longer runnable, and the program
crashes with a deadlock error, e.g.

       $ ruby -v -e"Thread.new{STDOUT.flush}.join"
       ruby 1.8.2 (2004-12-16) [alpha-vms] 
       deadlock 0x1bdf20: sleep:S  - thread.rb:1
       deadlock 0x1cc1e8: sleep:J(0x1bdf20) (main) - thread.rb:1
       thread.rb:1:in `join': Thread(0x1cc1e8): deadlock (fatal)
               from thread.rb:1    

Now, I'd like to fix this in the OpenVMS ruby port[1], but I don't know
how to "fake" a correct response from select() here:

	 n = select(max+1, &readfds, &writefds, &exceptfds, delay_ptr);

What should n, readfds, writefds and exceptfds be after this call?

Ben

[0] I have discussed this with other OpenVMS developers here:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=879
611

[1] By the way, we are working on the code for this port started by
Masamichi Akiyoshi that can be found here:
http://www.geocities.jp/vmsruby/en/
It appears he cannot continue with this work any longer, so we're doing
what we can to keep the port moving forward.