Volatile DB: non-locking reads

[mrBliss]

In the VolatileDB, not only writes require an exclusive lock (takeMVar) on the state of the VolatileDB, but reads too (instead of readMVar). This is because when a garbage collection (a write) happens concurrently with a read, e.g., getting a block from a file, it might be that the file to read from is deleted before we actually got to read the file. This will result in an FsError (FsResourceDoesNotExist?) when trying to read from the no longer existing file, which will close the VolatileDB, shutting down the node. The chances of this happening are small (getBlockComponent reads the state, then the garbageCollect locks the state and deletes the file before getBlockComponent does the actual read), but nonetheless problematic.

Also see this thread: #1165 (comment).

A potential solution is to use something like https://hackage.haskell.org/package/concurrent-extra-0.7.0.12/docs/Control-Concurrent-ReadWriteLock.html or https://hackage.haskell.org/package/concurrent-extra-0.7.0.12/docs/Control-Concurrent-ReadWriteVar.html. Note that we can't reuse these as we're using IOLike. We should allow concurrent reads, even reads concurrent with putBlock, but not reads concurrent with garbageCollect. To make things more complex, we could allow a putBlock call at the same time as garbageCollect, because we never garbage collect the file we append to.

Related: #1165.

Low priority, because we don't know how much time we lose because of the exclusive locks (we have always had them), and implementing this is complex (concurrency stuff always is) and harder to test.

[dcoutts]

I think we have an STM based reader/writer lock we could port over easily, if that's what we need.

[dcoutts]

If it helps, it's worth noting that Unix file systems allow one to delete files that are already open. So if existing readers have a handle to the file and keep it open, then there's nothing to stop GC from deleting the file. The file will actually be deleted automatically by the OS when the last open file handle is closed.

This behaviour is not supported on Windows however.

[mrBliss]

If it helps, it's worth noting that Unix file systems allow one to delete files that are already open. So if existing readers have a handle to the file and keep it open, then there's nothing to stop GC from deleting the file. The file will actually be deleted automatically by the OS when the last open file handle is closed.

This behaviour is not supported on Windows however.

We can't rely on this behaviour, because our pure/mock HasFS implementation does not implement it, as it's very hard to imitate it in a pure way. And if Windows doesn't support it either, then I think we should not pursue this option.

Furthermore, the file may have been deleted before we have opened it (unless we keep handles of all files open, as in #1165).