Question on fwrite
Author
If one uses fwrite to a file, is the file written at the point of the call? Or should I buffer my writes until I get a big enough lot before calling fwrite? I don't want to constantly write to the file on disk. Thanks.
fwrite use a buffer. When the buffer is full the buffer is written in the file.
You can verify this generating an error (like a division by zero) after a call of fwrite.
You can verify this generating an error (like a division by zero) after a call of fwrite.
Quote:Original post by apatriarca
fwrite use a buffer. When the buffer is full the buffer is written in the file.
You can verify this generating an error (like a division by zero) after a call of fwrite.
Off topic, I know, but does divide by zero work for that on a modern system? On a PowerPC Mac it merely yields a value of INF, but maybe Intel has different behaviour?
[Edited by - swiftcoder on September 8, 2006 7:03:30 AM]
Quote:Original post by swiftcoderQuote:Original post by apatriarca
fwrite use a buffer. When the buffer is full the buffer is written in the file.
You can verify this generating an error (like a division by zero) after a call of fwrite.
Does divide by zero work on a modern system? On a PowerPC Mac it merely yields a value of INF, but maybe Intel has different behaviour?
For floats it gets INF, on integers it generates an error.
Quote:Original post by rip-off
For floats it gets INF, on integers it generates an error.
Ah, thanks for clearing that up, on a PowerPC integer division by zero yields zero.
Quote:Original post by rip-off
For floats it gets INF, on integers it generates an error.
On the IA-32 platform (i.e. all Intel and compatible processors) there is also a mechanism for turning on floating-point exceptions, which are generated by the hardware for errors like Div-0, and other INF/NaN related problems unique to IEEE floats.
Author
When would it make sense to create a separate fwrite thread? If the OS is buffering the writes anyways, would it make sense? I mean if you create your own thread then you'll have to internally buffer your own write data and then signal a fwrite when you thought the buffer was big enough.
http://msdn2.microsoft.com/en-us/library/h9t88zwz.aspx
The Microsoft version is thread-safe. I don't know if it's required by the standard or if it depends on microsoft implementation.
The Microsoft version is thread-safe. I don't know if it's required by the standard or if it depends on microsoft implementation.
Quote:Original post by fathom88
When would it make sense to create a separate fwrite thread? If the OS is buffering the writes anyways, would it make sense? I mean if you create your own thread then you'll have to internally buffer your own write data and then signal a fwrite when you thought the buffer was big enough.
First off, the OS may be buffering the disk write but that has nothing to do with fwrite(). The fwrite() function is implemented in the C runtime library, so it's your application that's doing the buffering (unless you've turned it off with the fsetbuf() call).
Second, it makes sense under some circumstances to have a separate thread do the write when you're ding some CPU-intensive processing to produce the data, or when there is significant lag in the write. For example, if you're writing to a disk file on a remote share and the network connection is slow.
Sonce fwrite() is a synchronous call, your application will block between the time the OS is requested to start the write and the time it completes. All buffering does is postpone the wait, it doesn't eliminate it. If you're doing compute-intensive tasks and you don't want the CPU to waste valuable compute cycles while your fwrite() is waiting for the disk sectors to crawl under the write head, for bits to crawl along the USB bus, or for UDP packets to get switched back and forth across the network, you would do well to consider a separate write thread with your own buffering implemented.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
