openFile gives "file is locked" error on Linux when creating a non-existing file

[Harendra Kumar]

I just noticed that cabal seems to be running test suites in parallel.
We have two test suites. Even though each test suite generates the
temp names randomly, they use the same prefix, if the generated names
have a possibility of conflict due to PRNG it may cause a problem.
That is perhaps the more likely cause rather than hunting this in GHC.
cabal running tests in parallel without explicitly saying so came as a
surprise to me. In fact I found an issue in cabal repo asking for a
"feature" to run them sequentially, the issue is still open -
https://github.com/haskell/cabal/issues/6751 . Hopefully this is it.

-harendra

On Wed, 9 Oct 2024 at 08:34, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>
> On Tue, Oct 08, 2024 at 06:08:52PM +0530, Harendra Kumar wrote:
>
> > What if we closed a file and created another one and the inode of the
> > previous file got reused for the new one? Is it possible that there is
> > a small window after the deletion of the old one in which GHC keeps
> > the lock in its hash table?
>
> That SHOULD NOT happen, GHC releases the (internal hash table entry)
> lock before closing the file descriptor:
>
>     close :: FD -> IO ()
>     close fd =
>       do let closer realFd =
>                throwErrnoIfMinus1Retry_ "GHC.IO.FD.close" $
>     #if defined(mingw32_HOST_OS)
>                if fdIsSocket fd then
>                  c_closesocket (fromIntegral realFd)
>                else
>     #endif
>                  c_close (fromIntegral realFd)
>
>          -- release the lock *first*, because otherwise if we're preempted
>          -- after closing but before releasing, the FD may have been reused.
>          -- (#7646)
>          release fd
>
>          closeFdWith closer (fromIntegral (fdFD fd))
>
>     release :: FD -> IO ()
>     release fd = do _ <- unlockFile (fromIntegral $ fdFD fd)
>                     return ()
>
> Solved in GHC 7.8 11 years ago:
>
>     https://gitlab.haskell.org/ghc/ghc/-/issues/7646#note_68902
>
> This assumes that the application is not closing the file descriptor
> "behind GHC's back".  That is, you're not using the POSIX package to
> directly close file descriptors underlying Haskell file Handles
> (which would then orphan the associated "lock").
>
> --
>     Viktor.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs