On Tue, Aug 14, 2018 at 08:29:04PM +0200, Johannes Sixt wrote:
> Am 14.08.2018 um 00:37 schrieb Jeff King:
> > And then you can do something like:
> >
> >for size in 4097 8193 16385 32769 65537 131073 262145 524289 1048577; do
> > >out ;# clean up from last run
> > echo "Trying
Am 14.08.2018 um 00:37 schrieb Jeff King:
And then you can do something like:
for size in 4097 8193 16385 32769 65537 131073 262145 524289 1048577; do
>out ;# clean up from last run
echo "Trying $size..."
timeout 5 ./write $size out
if ! ./check $size
I used your
On Tue, Aug 14, 2018 at 03:47:54PM +0200, Ævar Arnfjörð Bjarmason wrote:
> The relevant POSIX docs are here:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html
>
> Write requests of {PIPE_BUF} bytes or less shall not be interleaved
> with data from other processes
Jeff Hostetler writes:
> On 8/13/2018 3:02 PM, Johannes Sixt wrote:
>>
>> Fortunately, Windows does support atomic O_APPEND semantics using the
>> file access mode FILE_APPEND_DATA. Provide an implementation that does.
>> ...
>>
>> Diagnosed-by: Johannes Schindelin
>> Helped-by: Jeff Hostetler
On Mon, Aug 13 2018, Jeff King wrote:
> On Mon, Aug 13, 2018 at 11:22:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > O_APPEND is POSIX and means race-free append. If you mark some call
>> > sites with O_APPEND, then that must be the ones that need race-free
>> > append. Hence, you would have
On 8/13/2018 3:02 PM, Johannes Sixt wrote:
The Windows CRT implements O_APPEND "manually": on write() calls, the
file pointer is set to EOF before the data is written. Clearly, this is
not atomic. And in fact, this is the root cause of failures observed in
t5552-skipping-fetch-negotiator.sh
On Mon, Aug 13, 2018 at 11:22:10PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > O_APPEND is POSIX and means race-free append. If you mark some call
> > sites with O_APPEND, then that must be the ones that need race-free
> > append. Hence, you would have to go the other route: Mark those call
> >
Ævar Arnfjörð Bjarmason writes:
> O_APPEND in POSIX is race-free only up to PIPE_MAX bytes written at a
> time, which is e.g. 2^12 by default on linux, after that all bets are
> off and the kernel is free to interleave different write calls.
We are only interested in the use of race-safe append
On Mon, Aug 13 2018, Johannes Sixt wrote:
> Am 13.08.2018 um 22:20 schrieb Junio C Hamano:
>> Johannes Sixt writes:
>>
>>> The Windows CRT implements O_APPEND "manually": on write() calls, the
>>> file pointer is set to EOF before the data is written. Clearly, this is
>>> not atomic. And in
Am 13.08.2018 um 22:20 schrieb Junio C Hamano:
Johannes Sixt writes:
The Windows CRT implements O_APPEND "manually": on write() calls, the
file pointer is set to EOF before the data is written. Clearly, this is
not atomic. And in fact, this is the root cause of failures observed in
Johannes Sixt writes:
> The Windows CRT implements O_APPEND "manually": on write() calls, the
> file pointer is set to EOF before the data is written. Clearly, this is
> not atomic. And in fact, this is the root cause of failures observed in
> t5552-skipping-fetch-negotiator.sh and
The Windows CRT implements O_APPEND "manually": on write() calls, the
file pointer is set to EOF before the data is written. Clearly, this is
not atomic. And in fact, this is the root cause of failures observed in
t5552-skipping-fetch-negotiator.sh and t5503-tagfollow.sh, where
different processes
12 matches
Mail list logo
