When does write() to a file return EWOULDBLOCK?

Question

I want to append data often to a file on the local filesystem. I want to do this without blocking for too long, and without making any worker threads. On Linux kernel 2.6.18.

It seems that the POSIX AIO implementation for glibc on Linux makes a userspace threadpool and blocks those threads. Which is cool, but I could just as easily spin off my own special dedicated file blocking thread.

• http://www.kernel.org/doc/man-pages/online/pages/man7/aio.7.html

And it's my understanding that the Linux Kernel AIO implementation currently blocks on append. Appending is the only thing I want to do.

• http://code.google.com/p/kernel/wiki/AIOUserGuide
• https://groups.google.com/forum/#!msg/linux.kernel/rFOD6mR2n30/13VDXRTmBCgJ

I'm considering opening the file with O_NONBLOCK, and then doing a kind of lazy writing where if it EWOULDBLOCK, then try the write again later. Something like this:

1. open(pathname, O_CREAT | O_APPEND | O_NONBLOCK);
2. call write(), check for error EAGAIN | EWOULDBLOCK
3. if EAGAIN | EWOULDBLOCK, then just save the data to be written and try the write() again later.

Is this a good idea? Is there any actual advantage to this? If I'm the only one with an open file descriptor to that file, and I try a write() and it EWOULDBLOCK, then is it any less likely to EWOULDBLOCK later? Will it ever EWOULDBLOCK? If I write() and it doesn't EWOULDBLOCK, does that mean write() will return swiftly?

In other words, under exactly what circumstances, if any, will write() to a local file fail with EWOULDBLOCK on Linux 2.6.18?

Answer 1

I'm not sure about local file system, but I'm pretty sure that you can get EWOULDBLOCK when trying to write to a file on a mounted file system (e.g. nfs). The problem here is that normally you don't know if it is really "local" hard disk unless you spefically check for this every time you create/open the file. How to check this is of course system dependent.

Even if system creates some additional thread to do the actual write, this thread would have a buffer (which would not be infinite), so if you write fast enough, you could get EWOULDBLOCK.

Answer 2

under ... what circumstances ... will write() to a local file fail with EWOULDBLOCK

Perhaps there is no circumstance for a file. The Linux man page for write(2) states that EWOULDBLOCK would only be returned for a file descriptor that refers to a socket.

EAGAIN or EWOULDBLOCK
The file descriptor fd refers to a socket and has been marked nonblocking (O_NONBLOCK), and the write would block. POSIX.1-2001 allows either error to be returned for this case, and does not require these constants to have the same value, so a portable application should check for both possibilities.

Apparently this behavior is related to the fact that a socket would employ record locks, whereas a simple file would not.