homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients bsdphk, pitrou, r.david.murray
Date 2012年08月18日.23:20:04
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1345331819.4150.16.camel@localhost.localdomain>
In-reply-to <1345331642.02.0.242995519821.issue15723@psf.upfronthosting.co.za>
Content
> Even if we write in chunks, if we are calling the OS write function
> and O_APPEND is set, wouldn't be satisfying the condition? Or,
> rather, the OS would be. That is, I don't really see a guarantee of
> an *atomic* write in the quoted description.
I'm not sure it's guaranteed to be atomic at the hardware level, but as
AFAIU the updates should be atomic as seen from other processes on the
same machine (i.e. filesystem cache coherency).
As a side-note, I've just tested under Linux with the following script:
 with open("foo", "ab") as f:
 f.write(b"abcd")
 f.write(b"x" * (1024 ** 2))
Results:
- on 2.7, the write buffers get sliced up (the glibc's fwrite() doesn't
care about atomicity):
write(3, "abcdxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 4096) = 4096
write(3, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 1044480) = 1044480
- on 3.2 and 3.3, our home-grown buffering respects the original
buffers:
write(3, "abcd", 4) = 4
write(3, "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"..., 1048576) = 1048576
(but that's purely out of luck, since we didn't design it with that
goal :-))
History
Date User Action Args
2012年08月18日 23:20:06pitrousetrecipients: + pitrou, r.david.murray, bsdphk
2012年08月18日 23:20:05pitroulinkissue15723 messages
2012年08月18日 23:20:04pitroucreate

AltStyle によって変換されたページ (->オリジナル) /