相关文章推荐
性感的椅子  ·  snd_pcm_set_params - ...·  4 周前    · 
深情的脆皮肠  ·  c fwrite fread-掘金·  9 月前    · 
安静的海龟  ·  java.lang.IllegalState ...·  9 月前    · 
个性的火柴  ·  Qt ...·  10 月前    · 
慷慨的烤面包  ·  nginx ...·  1 年前    · 
爽快的咖啡豆  ·  ASP.NET Web Forms 和 ...·  1 年前    · 
Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Learn more about Collectives

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Learn more about Teams

fwrite() may block. It uses (usually) an internal buffer with a maximum length. It will send the data (all or part of its internal buffer) when the buffer becomes full.

The setbuf() and setvbuf() functions let you alter the buffer maximum length, and actually provide the block for the buffer, but the details are implementation dependent, so you will have to read the documentation for your specific C library.

Conceptually, if you want guaranteed non-blocking writes under all conditions, then you need potentially infinite buffers, which can be somewhat expensive. You could make your own functions for buffering data (within a block of RAM, using realloc() to make it grow when necessary) and write out (with fwrite() and possible fflush() ) only at the end. Alternatively, you could try to use non-blocking I/O in which write functions never block but may respond that they refuse to accept your data due to internal congestion. Non-blocking I/O is not part of the C standard itself (there is no f*() function for that) but can be found under various names on some systems (e.g. with fcntl() and write() on Unix systems).

It's also important to note that even if fwrite blocks, all it's definitely doing is handing its data over to the kernel/filesystem layer. The kernel will typically do buffering of its own rather than sync the data to disk immediately. nobody Mar 22, 2010 at 16:07

Technically fwrite() is a blocking call in that it does not return until the procedure has completed. However the definition of completion for fwrite() is that the data you supply has been written to an internal file buffer. As a side effect some of that buffer may also be written to the disk as part of the fwrite() call but you cannot rely on that behavior. If you absolutely require the data to be on the disk you need to call fflush() .

If this is true then it does exactly what i need. By non-blocking i just meant that it shouldnt block while writing to disk.. i just need to set a huge buffer John Michaels Mar 22, 2010 at 16:18 Note that fflush only guarantees the data is moved from userland into the kernel. The kernel also buffers so if you lose power, you may still lose the data. If you truly want the data on disk, you would need to do a fsync(fileno(fp)); R Samuel Klatchko Mar 22, 2010 at 17:45 Well, as I said above, a side effect of calling fwrite() is that it might flush its internal buffer to disk. This indeterminacy will cause significant jitter in the length of time calls to fwrite() take. As Thomas Pornin said you can set the buffer size but details of when fwrite() will flush its buffer to disk are implementation dependent. If you truly want a deterministic non-blocking fwrite() equivalent you'll either need to defer that processing to a separate thread or write your data to intermediate staging area of memory and then call fwrite() once at the end. Andrew O'Reilly Mar 22, 2010 at 17:46 Any way to force fwrite not to fflush() internally? Cause thats waht i need.. i just call "write" and it puts it in a buffer and returns immediately and maybe it starts to write maybe not but it doesnt halt my program till i call flush John Michaels Mar 22, 2010 at 16:01

Thanks for contributing an answer to Stack Overflow!

  • Please be sure to answer the question . Provide details and share your research!

But avoid

  • Asking for help, clarification, or responding to other answers.
  • Making statements based on opinion; back them up with references or personal experience.

To learn more, see our tips on writing great answers .