Add a faster Windows specific rb_io_wait() implementation

[larskanis]

It is based on the code that was removed in commit 6c885e8

Fixes #416

CC: @jirubio

[ariccio]

Nit: both WSACreateEvent and WSACloseEvent can fail.

I'm basically the only programmer I've ever met who actually checks these kinds of return codes when writing low level code, but you'd be shocked at the number of bugs it's found, and the number of times it's saved my butt when debugging mysterious problems. Code I've written like this has even found bugs in WINE.

Perhaps you could rb_raise an rb_eConnectionBad, an rb_ePGerror, or a new and more specific exception type, in that case?

I usually find myself wrapping calls to handle-closing functions like WSACloseEvent (or plain old CloseHandle) in a little shim that checks the value, where I usually just std::terminate/abort (since this shouldn't happen unless I missed something), but aborting wouldn't make much sense here. If anything ever goes wrong that causes these to fail and it's not bubbled up to the interpreter, I bet someone will have a bad day :)

If you're compiling with MSVC, you can even annotate the param with _Frees_ptr_, (or _Post_ptr_invalid_, __drv_freesMem) to get static analysis to detect accidental use of closed event handles. You probably don't need this bit, but it's a cool fun fact that I haven't had an excuse to share for a few years now!

[larskanis]

@ariccio Thank you for your notes! I totally agree with you, but I judge this patch as a workaround only and would better invest my time into solving the slowness in ruby core. The code here worked for 11 years now.

[larskanis]

@ariccio If you provide a PR I'll merge it.

[ariccio]

I appreciate it! But my local environment is not setup right for compiling ruby modules right now. You're probably right that it's no big deal. I'll come back to this when I can find time!

Thanks for maintaining this package.