Windows support

[talex5]

Eio needs to support Windows. It was somewhat working with the libuv backend, but the other platforms have stopped using that now (see #434).

• We need OCaml 5.1 for Simplify and fix the shadow store reservation on Win64 ocaml/ocaml#11846 (OCaml 5.0 segfaults on Windows)

The current plan is:

• Create an eio_windows backend based on eio_posix (Posix-based windows implementation #497).
• Get eio_main working with Windows. Get the CI to run one of the examples.
• Set up CI to run the main set of tests on Windows (Get main test-suite running on Windows #761).
• Add initial FS support (Fs implementation for windows #509).
• Finish FS support (see Fs implementation for windows #509 (comment)).
• Need to decide about absolute paths (/C:/foo/bar?) and converting from native paths (Improve handling of Windows paths #762).
• Go through the backend and implement all the TODOs.
• Improve timer resolution (currently 1 second).

Later, we could convert the backend to use IOCP, but that's not ready yet.

[nojb]

Hiya, just FYI I am beginning to try this on Windows. I managed to build the library with the mingw64 compiler and the libuv backend (not completely trivial due to the many dependencies :)). A trivial test program

let () =
  Eio_luv.run @@ fun env ->
  let clock = Eio.Stdenv.clock env in
  Eio.traceln "The time is now %f" (Eio.Time.now clock)

fails with

Fatal error: exception Invalid_argument("Sys.signal: unavailable signal")

Fix is probably easy (just ignore signals?) but anyway, I don't think you should run to fix this one issue; I am planning to experiment a bit more and will report back (adding to this issue).

[talex5]

Ah, great! Yes, it probably just needs this disabled:

eio/lib_eio_luv/eio_luv.ml

Line 28 in 8beda18

let () = Sys.(set_signal sigpipe Signal_ignore)

(OCAMLRUNPARAM=b should give the location if not)

[nojb]

BTW what do you use for testing? The files in test/?

[talex5]

Yes. dune runtest should run all the tests.

make bench runs the benchmarks.

[nojb]

Yes. dune runtest should run all the tests.

Unfortunately they rely on mdx and its status on Windows is not very clear (see realworldocaml/mdx#295). I will try to run them manually.

[talex5]

Ah, is this because of different line-endings? It should be possible to configure Git to check the files out with Unix line endings, for testing. It looks like we're not using any shell blocks, so that should be OK.

[polytypic]

I'm looking into getting Eio working on Windows. I was just able to reproduce the signal issue:

C:\...\eio>make bench
dune exec -- ./bench/bench_buf_read.exe
+Read 100000000 bytes in 0.875s
dune exec -- ./bench/bench_mutex.exe
Fatal error: exception Invalid_argument("Sys.signal: unavailable signal")
make: *** [Makefile:8: bench] Error 2

[polytypic]

Some progress on Windows: After removing the set_signal call from eio_luv.ml, the benchmarks started to fail with a segfault. The cause of the segfault turned out to be a compiler bug, see PR. I have verified that with the PR the segfaults from benchmarks are gone.

I plan to continue with trying to get mdx working on Windows for running tests.

There also appears to be at least one Obj.magic call in eio_luv.ml that will not work on Windows.

[talex5]

That's excellent progress!

BTW, there are now some examples you can run that will test libuv and don't need MDX (though getting MDX working so we can run the tests is still important, of course):

$ dune exec -- ./examples/hello/main.exe
Hello, world!

$ dune exec -- ./examples/net/main.exe
+client: Connecting to server at tcp:127.0.0.1:8080...
+server: Accepted connection from tcp:127.0.0.1:38524
+server: Received: "Hello from client"
+client: Got reply "OK"

[patricoferris]

I was wondering if it might be useful to have a more substantial set of tests that don't rely on MDX? There are two (related) uses cases for them in my mind:

• Adding a new backend e.g. GCD. Tests are really useful to help get the implementation right, but MDX doesn't offer a particularly friendly interface for running a single test or debugging when I inevitably get the implementation wrong.
• The Javascript backend (PR coming soon...) won't work with MDX and it would be nice to have a suite of tests we can run (Alcotest for example supports running in Node and can support the browser too).

If there's a desire for this I can open a separate issue, just saw this comment so replied here.

[talex5]

Yes, it would be nice if MDX made debugging easier! It does have --section, which might help. But dune runtest doesn't pass arguments though (it doesn't for other test frameworks either). Also, I usually put some helpers at the start, so it would need to know to run that bit in all cases.

As a work-around, I sometimes indent the bit of the file I don't want to test with 4 spaces, so MDX ignores it. Or use dune runtest &| head -$LINES to see the first error instead of the last (note: this is fish syntax).

I guess it would be fairly easy to get MDX to generate stand-alone expect tests from the .md files. ocaml-mdx pp file.md already generates OCaml code, but it doesn't include the expected output.