IPV4/IPV6 over loopback spec has a race condition

[gvvaughan]

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!

[zevv]

• 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?

[gvvaughan]

Hi Zevv,

1. The plan is to make minimal bindings in ext/posix/posix.c, and then to write more pleasant/Luaish wrappers in lib/posix/sys.lua, however for backwards compatibility we might put a wrapper in lib/posix.lua that issues a deprecation warning to ease people into the new API.
2. 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

[zevv]

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.

[zevv]

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?

[gvvaughan]

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