Duy Nguyen writes:
> On Sat, Apr 12, 2014 at 11:19 AM, Junio C Hamano wrote:
>
>> In the spectrum between useful and insane, there is a point where we
>> should just tell the insane: don't do it then.
>
> ... A process' dying is a
> way of telling people "this is insane" without having to draw a
On Sat, Apr 12, 2014 at 11:19 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Sat, Apr 12, 2014 at 3:43 AM, 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 sa
Junio C Hamano writes:
> What is the race under discussion about? It is about the index,
> which corresponds one-to-one to the working tree, so in order for
> the "race" to matter, you need to be racing against another process
> that is not cooperating with you (e.g. a continuous and uncontrolle
Duy Nguyen writes:
> On Sat, Apr 12, 2014 at 3:43 AM, 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.
>
> When it comes to racing, sanity does not matt
On Sat, Apr 12, 2014 at 3:43 AM, 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.
When it comes to racing, sanity does not matter much. People could
just do
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
Junio C Hamano 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
>
Duy Nguyen writes:
> On Fri, Apr 11, 2014 at 2:28 AM, Junio C Hamano wrote:
>> Yiannis Marangos writes:
>>
>>> + n = xpread(fd, sha1, 20, st.st_size - 20);
>>> + if (n != 20)
>>> + goto out;
>>
>> I think it is possible for pread(2) to give you a short-read.
>>
>> The existi
On Fri, Apr 11, 2014 at 09:47:09AM +0200, Torsten Bögershausen wrote:
> 6. process A applies a commit:
> - read the index into memory
> - take the lock
> - update the index file on disc
> - release the lock
So here we can have race condition. Maybe we should implement Duy
On Fri, Apr 11, 2014 at 2:28 AM, Junio C Hamano wrote:
> +static int verify_index_from(const struct index_state *istate, const char
> *path)
> +{
> + int fd;
> + ssize_t n;
> + struct stat st;
> + unsigned char sha1[20];
> +
> + if (!istate->initialized)
> +
On 2014-04-10 21.28, Junio C Hamano wrote:
> Yiannis Marangos writes:
>
>> +n = xpread(fd, sha1, 20, st.st_size - 20);
>> +if (n != 20)
>> +goto out;
>
> I think it is possible for pread(2) to give you a short-read.
>
> The existing callers of emulated mmap and index-pack ar
On Fri, Apr 11, 2014 at 2:28 AM, Junio C Hamano wrote:
> Yiannis Marangos writes:
>
>> + n = xpread(fd, sha1, 20, st.st_size - 20);
>> + if (n != 20)
>> + goto out;
>
> I think it is possible for pread(2) to give you a short-read.
>
> The existing callers of emulated mmap and
Yiannis Marangos writes:
> + n = xpread(fd, sha1, 20, st.st_size - 20);
> + if (n != 20)
> + goto out;
I think it is possible for pread(2) to give you a short-read.
The existing callers of emulated mmap and index-pack are prepared to
handle a short-read correctly, but I do n
13 matches
Mail list logo
