take lock in checkLogFile and calcLogFile

move: Fix openFile crash with -J

This does make them a bit slower, although usually the log file is not
very big, so even when it's being rewritten, they will not block for
long taking the lock. Still, little slowdowns may add up when moving a lot
file files.

A less expensive fix would be to use something lower level than openFile
that does not check if the file is already open for write by another
thread. But GHC does not seem to provide anything convenient; even mkFD
checks for a writing thread.

fullLines is no longer necessary since these functions no longer will
read the file while it's being written.

Sponsored-by: Dartmouth College's DANDI project
This commit is contained in:
Joey Hess 2022-10-07 13:19:17 -04:00
parent 85dbc21c1c
commit 4a42c69092
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 48 additions and 45 deletions

View file

@ -40,3 +40,5 @@ git-annex version: 10.20220927
[[!meta author=yoh]]
[[!tag projects/dandi]]
> Presumed [[fixed|done]]; please followup if I'm wrong. --[[Joey]]

View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2022-10-07T16:44:04Z"
content="""
I doubt this is really OSX specific. This must be two threads running logMove
at the same time, that end up trying to both write or one write and one
read at the same time. That causes the haskell RTS to fail this way.
Since it does use a lock file when writing and appending to the log file,
I think it must be the call to checkLogFile that is failing. That avoids
taking the lock, for performance reasons. The performace gain is pretty
minimal though, taking the lock is not much. Only when modifyLogFile
is called at the same time might it need to block on the file being
rewritten, but the file only ever has 100 items, so that never takes long
either.
So, I have added locking to checkLogFile (and to calcLogFile though it's
not used here, just because it has the same problem). That should fix it,
though we'll need to wait on the test to know for sure. I'm going to close
this, as I'm pretty sure though..
"""]]