Hi Duy, On Fri, 18 Mar 2016, Duy Nguyen wrote:
> On Fri, Mar 18, 2016 at 2:17 PM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > > > On Fri, 18 Mar 2016, Duy Nguyen wrote: > > > >> > Well, the way I read the code it is possible that: > >> > > >> > 1. Git process 1 starts, reading the index > >> > 2. Git process 2 starts, poking the index-helper > >> > 3. The index-helper updates the .pid file (why not set a bit in the > >> > shared > >> > memory?) with a prefix "W" > >> > 4. Git process 2 reads the .pid file and waits for the "W" to go away > >> > (what if index-helper is not fast enough to write the "W"?) > >> > 5. Git process 1 access the index, happily oblivious that it is being > >> > updated and the data is in an inconsistent state > >> > >> No, if process 1 reads the index file, then that file will remain > >> consistent/unchanged all the time. index-helper is not allowed to > >> touch that file at all. > >> > >> The process 2 gets the index content from shm (cached by the index > >> helper), verifies that it's good (with the signature at the end of the > >> shm). If watchman is used, process 2 can also read the list of > >> modified files from another shm, combine it with the in-core index, > >> then write it down the normal way. Only then process 1 (or process 3) > >> can see the new index content from the file. > > > > So how do you deal with releasing the shared memory instances that are > > essentially created for every index update? > > When index-helper reads the index file and realizes the file has been > updated (based on trailing SHA-1), it unlink()s the old shm and > prepares new shm. If no process is accessing old shm, it's gone. If > not, it stays until nobody elses uses it. shm on Windows behaves the > same way, I believe. Ah. On Windows, you do not even have to unlink: once the last user's gone, the shared memory's gone, too. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
