-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add IO tests #270
Add IO tests #270
Conversation
These tests take quite some time, in particular Anyway, should these tests be disabled in standard runs? |
I’m not sure I understand the issue in that run |
Modulo the failing I was just looking at the log and spotted this gem from macOS 5.0.0:
A sequential execution - which fails with |
The runtime code that closes a channel (here) doesn’t seem to leave the place for such non-determinism: the descriptor is invalidated while holding the channel lock. |
After reading the code again, in those circumstances, I think the content of the internal buffer that’s returned when doing the Simple test: let _ =
let f = open_in Sys.argv.(0) in
seek_in f 4 ;
close_in_noerr f ;
seek_in f 0 ;
Printf.printf "Read: %d\n%!" (input_byte f) ;
Printf.printf "Read: %d\n%!" (input_byte f) ;
Printf.printf "Read: %d\n%!" (input_byte f) ;
Printf.printf "Read: %d\n%!" (input_byte f) ;
Printf.printf "Read: %d\n%!" (input_byte f) gives:
|
The bug encountered by this strange run was reported in ocaml/ocaml#11878. |
Should we rebase this to have a clean CI run? (the previous one had several unrelated CI failures adding noise) |
Since those modules are not thread-safe, these are negative tests
Lin_thread tests take up much time without revealing much compared to Lin_domain tests Tests using the internal API cover only a small part of the API
This looks all green, modulo a |
Let’s! |
Add tests for
In_channel
andOut_channel
.Rebase and fix @OlivierNicole’s Lin tests (#13). Add tests using the Lin DSL.