On Tue, 30 Apr 2002, at 12:00pm, [EMAIL PROTECTED] wrote: > ... setvbuf only controls buffering between the app and the stream/file > it's writing to, whereas f*sync is essentially an OS buffer control > mechanism?
More or less. Gory details: The C standard I/O library (stdio) defines files as "streams" (of bytes). When you use fopen(3) to open a file, you are invoking the stdio function that creates a stream. Now, stdio performs buffering between stdio functions like fread(3) and fwrite(3) and the actual read(2) and write(2) system calls. This buffering takes place entirely in the userland memory space allocated to your program. This buffer is typically of a fixed size per stream, and comparatively small (a few kilobytes, I think). The setvbuf(3) function can control the buffering in the stdio library. The Unix API defines "file descriptors" (FDs). System calls like open(2) and write(2) work with FDs. The stdio library is basically a wrapper around these FDs. The kernel performs its own buffering on files and devices. The kernel's buffer cache is dynamic, and can easily grow to tens or even hundreds of megabytes. Userland programs generally see little of this. The system calls fsync(2) and fdatasync(2) are exceptions to that rule. They provide a way for a userland program to ask the kernel to make sure all its buffers for a particular file are written out to disk. The reason stdio has its own buffering is that system calls are expensive. If you call fwrite(3) five times, writing one byte each time, stdio might buffer that into a single write(2) call of five bytes. That saves four transitions to kernel mode and back. Exactly what goes on when the system has to switch privilege levels is over my head, but I think the kernel has to bow five times towards Finland and recite the ASCII code backwards, or something like that. Remember, any time you see foo(3), it is a userland function. Any time you see bar(2), it is a system call. There are gazillions of userland functions, but only a few hundred system calls. A system call means you are talking directly to the kernel. For more information, see stdio(3) and syscalls(2). -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ***************************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the text 'unsubscribe gnhlug' in the message body. *****************************************************************
