> So it's probably a wash. In that case, do we want to maintain two hacks for > this? I can't use the FLOCKFILE/etc approach on Windows, while "the > Windows" approach probably works everywhere (although its speed relies on > the platform factoring out at least the locking/unlocking in fgets). I'm much more confident about the getc_unlocked() approach than about fgets() -- with the latter we need much more faith in the C library implementers. (E.g. that fgets() never writes beyond the null bytes it promises, and that it locks/unlocks only once.) Also, you're relying on blindingly fast memchr() and memset() implementations. > Both methods lack a refinement I would like to see, but can't achieve in > "the Windows way": ensure that consistency is on no worse than a per-line > basis. [Example omitted] The only portable way to ensure this that I can see, is to have a separate mutex in the Python file object. Since this is hardly a common thing to do, I think it's better to let the application manage that lock if they need it. (Then why are we bothering with flockfile(), you may ask? Because otherwise, accidental multithreaded reading from the same file could cause core dumps.) --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4