file.seek()/write() in main process and file.flush() in thread
Clash Royale CLAN TAG#URR8PPP
file.seek()/write() in main process and file.flush() in thread
I've opened a file with open(..., 'r+b'), is it safe to call .flush() in a thread while the main process is performing .read()/.write()/.seek() operations on this file in Python 3.6+?
open(..., 'r+b')
.flush()
.read()
.write()
.seek()
The goal is to be able to read/write quickly using the buffer but to offload the flush into a thread (assuming it is the most expensive operation).
Any other tips or gotchas with this approach?
fsync()
flush()
fsync()
flush()
...it would be a lot more straightforward to put the content you're writing onto a queue, and have a separate thread read from the queue, write to the sink, and flush. That way you aren't depending on any semantics that aren't well-documented.
– Charles Duffy
Aug 12 at 16:08
(To be clear, a
.write() to a buffered stream that isn't long enough to trigger a flush() automatically, and doesn't otherwise trigger a write -- as by containing a newline if the stream is line-buffered -- isn't actually doing any OS-level work at all: it's just appending content to a buffer, managed by the local libc, that's going to be written later, on flush or close).– Charles Duffy
Aug 12 at 16:14
.write()
flush()
By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.
See oldblog.antirez.com/post/fsync-different-thread-useless.html, f/e, re:
fsync()on a different thread being useless. Admittedly, this isn't the same thing asflush()--fsync()ensures content is flushed to disk (and survives a reboot), whereasflush()ensures it's flushed to the OS (and visible to other processes) -- but there can be similar issues in play (depending on how your libc manages its buffers).– Charles Duffy
Aug 12 at 16:05