<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Mar 21, 2014 at 10:45 AM, Stephen Blott <span dir="ltr"><<a href="mailto:smblott@gmail.com" target="_blank">smblott@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

The issues are described below.  However, fundamentally, the problem is that password-store is doing concurrent programming without any concurrency control.  Which doesn't work.<br></blockquote><div><br></div><div>The current solution, which uses signals, which is in fact a concurrency primitive.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
<br>
   - <a href="https://github.com/smblott-github/password-store/compare/locking" target="_blank">https://github.com/smblott-<u></u>github/password-store/compare/<u></u>locking</a></blockquote><div><br></div><div>In the future, would you mind using git-send-email? I could then reply inline about code issues.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br><br>
<br>
1. With two concurrent background processes, the second restores the first's password, leaving a password in the clipboard.<br>
<br>
2. With two concurrent background processes, the clipboard is restored by the first before the 45 seconds of the second have elapsed.<br><br></blockquote><div><br></div><div>The current solution using that "kill" line solves these two issues in basically 3 lines: <a href="http://git.zx2c4.com/password-store/commit/?id=2c9c36e3ca8eab1a3f9056d18619f80cedf3781d">http://git.zx2c4.com/password-store/commit/?id=2c9c36e3ca8eab1a3f9056d18619f80cedf3781d</a></div>
<div><br></div><div>Your solution is quite hefty and writes passwords unencrypted to disk (!). An improvement to this would be to use tmpfs, as we do for `pass edit`. Also, you'll probably want to use $DISPLAY as part of the write/read lock file names, since a user might be using the same store with multiple X servers at once.</div>
<div><br></div><div>Anyway -- can you raise any technical arguments as to why the flock solution is better? I agree that my "sleep 0.1" is technically racy (though this could be fixed by inotify watching on /proc/$ppid and checking the monotonic start time bla bla), but in practice it seems to be pretty perfect.</div>
</div></div></div>