Epoll on regular files

Question

Can epoll (on Linux) be somehow useful for regular files? I know it's primarily used with sockets but just wonder.

Newsom

Answer 1

Not really. epoll only makes sense for file descriptors which would normally exhibit blocking behavior on read/write, like pipes and sockets. Normal file descriptors will always either return a result or end-of-file more or less immediately, so epoll wouldn't do anything useful for them.

Weakwilled

That is, it functions, though meaninglessly: "The poll() function shall support regular files... Regular files shall always poll TRUE for reading and writing." pubs.opengroup.org/onlinepubs/009695399/functions/poll.html The epoll(4) man page says: "when used as a Level Triggered interface, epoll is by all means a faster poll(2), and can be used wherever the latter is used since it shares the same semantics." Therefore, as duskwuff says, it won't do anything useful. – Wheelbase

Which is so silly and wrong. The kernel could hang up for a lot of reasons, from disk spin up (if asleep), down to network lag from a network mounted share/drive. Any kind of device interaction could cause an IO hang. select/epoll/poll/kqueue should be made to work with any file descriptor as well as any file description should allow non blocking. – Clearly

@Clearly That isn't possible. The kernel doesn't know ahead of time whether a write to a file will block -- unlike sockets or pipes, buffers for filesystem writes are not dedicated to a single FD, so there's no way to guarantee they will be available for a specific process. – Weakwilled

@duskwuff sure it can, it just chooses not to due to specific restraints. For example, the kernel knows what the buffers contains. Epoll in general isn't a guarantee of anything. Just more than likely. In theory anyway, readahead, could "ask" the system for specific data, and put a EPOLLIN/EPOLLERR signal into the epoll queue. Also, just because it DOESN'T do it, doesn't mean it still isn't silly and/or wrong. How the implementation is done is irrelevant to how it should function. – Clearly

In this repo it is said that "Linux has limited support for using epoll as a mechanism for asynchronous I/O [...] if the file is opened as O_NONBLOCK, then a read will return EAGAIN until the relevant part is in memory", which contradicts this answer. But in a simple test I couldn't confirm that. Who's right? – Meridel

@Meridel I'd say that document is wrong. lwn.net/Articles/612483 has some background -- in particular, open(…, O_NONBLOCK) is currently interpreted as only making opening the file nonblocking, not subsequent I/O operations. – Weakwilled

Contra the last comment, man 2 open says WRT O_NONBOCK: "Neither the open() nor any subsequent I/O operations on the file descriptor which is returned will cause the calling process to wait." However, it also notes (with a few qualifications that "this flag has no effect for regular files". – Affection

Answer 2

I think, it will fail at epoll_ctl with EPERM:

   EPERM  The target file fd does not support epoll.

if the file has no poll() interface.

The actual code is http://lxr.linux.no/#linux+v3.1/fs/eventpoll.c#L1373

1373    /* The target file descriptor must support poll */
1374        error = -EPERM;
1375        if (!tfile->f_op || !tfile->f_op->poll)
1376                goto error_tgt_fput;
1377

Rotorua