[ruby-core:23571] questions on recv in windows 1.9

Couple of questions, if anyone out there has feedback:

1) currently calls to read are replaced (via #define) with
rb_w32_recv.  This worked out of the box in 1.8, however with 1.9
rb_w32_recv now defaults to blocking, causing code to behave
differently on windows than on Linux--I think this is inadvertent and
should be classed as a bug?

2) when you perform any read on a socket, ex:

>> a = TCPSocket.new 'google.com', 80
=> #<TCPSocket:0x15ab060>
>> a.recv 1024

it waits for input with the following stack trace shown by process explorer:

ntoskrnl.exe!ExReleaseResourceLite+0x1a3
ntoskrnl.exe!PsGetContextThread+0x329
ntoskrnl.exe!FsRtlInitializeFileLock+0x83f
ntoskrnl.exe!FsRtlInitializeFileLock+0x87e
ntoskrnl.exe!ProbeForWrite+0x505
ntoskrnl.exe!ZwYieldExecution+0xb78
ntdll.dll!KiFastSystemCallRet
kernel32.dll!WaitForMultipleObjects+0x18
msvcrt-ruby191.dll!rb_vm_bugreport+0x27c
msvcrt-ruby191.dll!listen+0x3da
msvcrt-ruby191.dll!rb_w32_recvfrom+0x35
socket.so+0x1c32
msvcrt-ruby191.dll!rb_thread_blocking_region+0x60
socket.so+0x26c5
...

however, when you run a backtrace on it from within gdb, it shows:
(gdb) thread apply all backtrace
Thread 1 (thread 188.0x4ec):
#0  0x7c90e514 in ntdll!LdrAccessResource ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x7c90df4a in ntdll!ZwWaitForMultipleObjects ()
   from C:\WINDOWS\system32\ntdll.dll
#2  0x7c809590 in KERNEL32!CreateFileMappingA ()
   from C:\WINDOWS\system32\kernel32.dll
#3  0x7c80a115 in WaitForMultipleObjects ()
   from C:\WINDOWS\system32\kernel32.dll
#4  0x62e17c87 in w32_wait_events (events=0x22f9d0, count=2,
    timeout=4294967295, th=0x3e4370) at thread_win32.c:119
#5  0x62e17cd4 in rb_w32_wait_events_blocking (events=0x22f9d0, num=1,
    timeout=4294967295) at thread_win32.c:142
#6  0x62e2776f in overlapped_socket_io (input=1, fd=3,
    buf=0xed30f8 "\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r
≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r
≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r
≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║"..., len=1024, flags=0, addr=0x22fb00,
    addrlen=0x22fafc) at ./win32/win32.c:2765
#7  0x62e278c4 in rb_w32_recvfrom (fd=3,
    buf=0xed30f8 "\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r
≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r
≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r
≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║\r≡¡║"..., len=1024, flags=0, from=0x22fb00,
    fromlen=0x22fafc) at ./win32/win32.c:2806
#8  0x6e6015c2 in recvfrom_blocking (data=0x22faf0) at init.c:88
#9  0x62e197f9 in rb_thread_blocking_region (
    func=0x6e60151c <recvfrom_blocking>, data1=0x22faf0,
    ubf=0x62e183a7 <ubf_handle>, data2=0x3e4370) at thread.c:1047
#10 0x6e601701 in _fu0__rb_eIOError () at init.c:119
#11 0x6e60c808 in bsock_recv (argc=1, argv=0x9c0040, sock=4113528)
    at basicsocket.c:601
...

anybody have any idea why the first backtrace "thinks" that it ran
through rb_vm_bugreport? Odd.

Thanks for your consideration.
-=r