Home/ Questions/Q 9181373
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-17T18:17:54+00:00

I want to append data often to a file on the local filesystem. I

  • 0

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.

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

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0