hDuplicateTo001 fragile under CI
In this build (
x86_64-linux-deb9-debug job) the
hDuplicateTo001 test failed with:
Wrong exit code for hDuplicateTo001(threaded2)(expected 0 , actual 1 ) Stderr ( hDuplicateTo001 ): hDuplicateTo001: tmp: hDuplicateTo: resource busy (Device or resource busy) *** unexpected failure for hDuplicateTo001(threaded2)
This is the only time I have seen this failure.
hDuplicateTo ultimately calls
GHC.IO.Handle.dupHandleTo). The manpage for
dup2 claims that this error might be returned if:
EBUSY (Linux only) This may be returned by dup2() or dup3() during a race condition with open(2) and dup().
In other words, we asked the kernel to make the file descriptor
dest a duplicate of handle
src, but while this operation was underway another thread allocated
It's rather unclear what to do here. I can see how this would happen but it's quite unclear what we can do about this. It seems to me like it is nearly impossible to use this operation in the threaded runtime, given how little control you have over when and how fds are allocated.
I'm going to disable this test in the threaded way.