luaposix
luaposix copied to clipboard
IPV4/IPV6 over loopback spec has a race condition
https://travis-ci.org/luaposix/luaposix/jobs/33012265
Luajit build spuriously fails with:
socket handling
communicates with IPV4 and IPV6 over loopback
./specs/posix_spec.yaml:806:4: PENDING expectation 4: returning `true` is NOT a minimal binding!
./specs/posix_spec.yaml:806:5: PENDING expectation 5: issue #92 passed unexpectedly!
./specs/posix_spec.yaml:806:6: PENDING expectation 6: issue #92 passed unexpectedly!
- I could indeed (should maybe) fix the return values of some of the functions which return true instead of 0. This will result in an API change though, and might break code for some people.
- There's a number of reasons why the sendto() test might fail, I'm still not sure if doing socket I/O in an automated test is very reliable, but maybe it's possible to make specl print the return values of the sendto() so we can diagnose the underlying problem?
Hi Zevv,
- The plan is to make minimal bindings in
ext/posix/posix.c
, and then to write more pleasant/Luaish wrappers inlib/posix/sys.lua
, however for backwards compatibility we might put a wrapper inlib/posix.lua
that issues a deprecation warning to ease people into the new API. - socket I/O is deterministic, so we really should be able to write reliable tests in Specl I think. However, I haven't seen travis throw this error for a while, so the race condition seems to be winning in our favour at the moment, making the only way to diagnose it by inspection :-( Any insights very gratefully received of course!
Cheers, Gary
Sock I/O is deterministic, as long as you have full control over a stable test environment. Travis is a bit of a special case because of the virtualisation, so I guess results might vary between runs when the people at Travis make changes to their environent.
So, what do you think; shall I fix the socket functions to return proper POSIX return values instead of true/false (the way they should have been from the beginning), and we accept breaking compatibility for current users?
I don't think we need to break backward compatibility, but otherwise yes, please go ahead and fix the return values if you'd like. Before the next release, I'll patch up posix/sys.lua to return true/false and posix.lua to call posix/sys.lua APIs with deprecation warnings. A release or two after that, I'll remove the deprecated compatibility wrappers having given users enough time to upgrade their calls :)
Cheers, Gary