Message134071
| Author |
ronaldoussoren |
| Recipients |
nadeem.vawda, ronaldoussoren, sdaoden, vstinner |
| Date |
2011年04月19日.15:44:42 |
| SpamBayes Score |
2.032194e-07 |
| Marked as misclassified |
No |
| Message-id |
<1303227882.99.0.244463586551.issue11877@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Traditionally the functions in os are thin wrappers around OS functions, this patch changes that for os.fsync.
Two nits wrt. the patch itself:
1) The behaviour on OSX should be documented in the stdlib reference,
that currently says that os.fsync will call the C function fsync
2) The comment in the __APPLE__ case can be clearer, and should
explain the issue (as short as possible).
I'm -1 on merging this patch though, as the fsync function on OSX behaves just like the one on Linux, the fnctl option adds a stronger guarantee in that it forces a flush of the buffers on the storage device as well. The manpage for fsync on a linux host says:
In case the hard disk has write cache enabled, the data may not really be on permanent storage when fsync/fdatasync return.
Adding the F_FULLSYNC option to os.fsync would be fine though (if it isn't already implemented)
The linux |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2011年04月19日 15:44:43 | ronaldoussoren | set | recipients:
+ ronaldoussoren, vstinner, nadeem.vawda, sdaoden |
| 2011年04月19日 15:44:42 | ronaldoussoren | set | messageid: <1303227882.99.0.244463586551.issue11877@psf.upfronthosting.co.za> |
| 2011年04月19日 15:44:42 | ronaldoussoren | link | issue11877 messages |
| 2011年04月19日 15:44:42 | ronaldoussoren | create |
|