-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Race condition on history file with multiple REPLs #1634
Comments
Looking into this. I see two possible solutions. If anyone has a better idea, please let me know!
|
Option 1 can work as long as the files are on the same mount. Option 2 has portability issues and is unreliable with NFS. |
can we see what bash does and copy that? |
What about mmap'ing the file & setting a semaphore byte? This might be a bit too heavyweight of a solution, since it would require mmap support be added to libuv. |
Just for the record: this happens so frequently not because of racing writes but because both REPLs have the history file open in 'w' mode, one REPL exits and writes some history, and the other REPL exits and writes a shorter history, leaving behind some trailing bytes from the longer history. |
It seems like since we moved away from using json, this is no longer prevalent. Do we still need to implement some sort of locking to prevent corruption? |
Locking would probably be desirable if someone wants to take it up. It would be pretty complex though. |
I started working on a locking implementation for this, but I'm not totally clear on the desired behavior. If multiple REPLs are open should history be interleaved? Or is it last-write-wins behavior? |
@lance either or. I'd prefer interleaved. Most terminals do last-write-is-latest-history. |
Removed |
This issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that. |
via @substack
The text was updated successfully, but these errors were encountered: