IO.select fails on MSVC

[cyberarm]

I'm trying to use IO.select to monitor sockets; It works on CRuby but crashes on MRuby.

Script
https://github.com/cyberarm/broadcast_forwarder_wireguard/blob/e50413f37070cdaf88795a06d1f4a18c26bc09b0/broadcast_forwarder_wireguard.rb

I added a printf("WSAGetLastError: %i\n", WSAGetLastError()); inside of

mruby/mrbgems/mruby-io/src/io.c

Line 1261 in 1508da4

if (errno != EINTR)

According to WSAGetLastError() its caused by WSAEINVAL
https://docs.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2

Backtrace

WSAGetLastError: 10022
trace (most recent call last):
        [4] broadcast_forwarder_wireguard.rb:74
        [3] broadcast_forwarder_wireguard.rb:74:in new
        [2] broadcast_forwarder_wireguard.rb:15:in initialize
        [1] broadcast_forwarder_wireguard.rb:33:in monitor_broadcasts
broadcast_forwarder_wireguard.rb:33:in select: Unknown error: 0 - select failed (SystemCallError)

Build Config

MRuby::Build.new do |conf|
  conf.toolchain
  
  conf.gembox 'default'
  conf.gem :github => 'mattn/mruby-json'
  
  conf.enable_debug
end

[matz]

Unfortunately, mruby-socket assumes sockets can be represented by file descriptors (as UNIX does), but it's not true for WIN32 system using MSVC. CRuby implements an emulation layer on top of Windows socket. But it's not affordable for us. Your options are:

• use MSYS that provides emulation layer by itself
• use WSL

Our (future) options are:

• leave it as it is
• make mruby-socket to raise a build error on MSVC
• implement emulation layer for mruby (need expert to volunteer)

What's your opinion?

[cyberarm]

I see, that is unfortunate; I'll try using MSYS.

In the short term it would be good if it threw a descriptive error on MSVC that it isn't supported.
Eventually, it would be nice if it "Just Worked" like CRuby.

[matz]

Will do, but I need to find a macro symbol to distinguish MSVC first (_WIN32 is defined for MSYS too).

[llothar]

The ignorance of the Windows platform with the arrogance to call mruby cross platform is unfortunately still high. I tried to raise this point 15 year ago but nobody listened.

There would be quite a few API changes required. For example symlink on windows depends if it is a symbolic link to a file or a directory and the caller has to know this before invoking symlink, so two new functions are required. Just one more example. I burned out 10 years ago to talk about it, it's worthless as long as there is no shift in mentality. mruby could be such a nice embedded language if it would be written with more openess and less unix in mind.

Using MSYS is not a solution. There are still many things that require to use visual studio compiler and the whole new Windows Application SDK is not going to be able to use gcc/clang despite all the attempts another subgroup at Microsoft made to bring clang to windows.

[matz]

I agree with you. We need more contributors with Windows knowledge to be "real" cross-platform.
Besides that, the original Ruby behavior is designed under UNIX mind, we can not change this.
But good point is mruby I/O features are separated in mrbgems, so that we can implement Window I/O mrbgems.

[Asmod4n]

If you feel a bit adventurous you could try compiling mruby with https://github.com/jart/cosmopolitan.
It provides a posix API which mruby expects and cross compiles one statically linked binary for 7 different platforms, including windows.