On Fri, Mar 18, 2016 at 2:17 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi Duy, > > 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. -- Duy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html