Junio C Hamano [off-list ref] writes:
Yeah, I was hoping that the real write codepath (as opposed to "this
is read only and we read the index without holding a lock---now we
noticed that the index needs refreshing, and we know how the
resulting refreshed index should look like, perhaps we can write it
to save cycles for other processes" codepath where we cannot and
should not take a lock early) would take the lock and then read, but
because that is not the way they work, the need the same protection,
I would think.
Having said that, nobody sane would be running two simultaneous
operations that are clearly write-oriented competing with each other
against the same index file. So in that sense that can be done as a
less urgent follow-up for this topic.
On Fri, Apr 11, 2014 at 01:43:47PM -0700, Junio C Hamano wrote:
Having said that, nobody sane would be running two simultaneous
operations that are clearly write-oriented competing with each other
against the same index file. So in that sense that can be done as a
less urgent follow-up for this topic.
I'm willing to take this task, I decide to spend some of my free time
for git development. But since I'm a newbie with it's architecture I
don't know when it will be ready because I want to explore the code a
bit.
--
Yiannis
On Sat, Apr 12, 2014 at 3:43 AM, Junio C Hamano [off-list ref] wrote:
Having said that, nobody sane would be running two simultaneous
operations that are clearly write-oriented competing with each other
against the same index file.
When it comes to racing, sanity does not matter much. People could
just do it without thinking what exactly is happening behind the
scene.
So in that sense that can be done as a less urgent follow-up for this topic.
Yeah if racing at refresh time is a real problem, sure we should solve it first.
--
Duy