30

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

Cartesius00
  • 23,584
  • 43
  • 124
  • 195

2 Answers2

26

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.

  • 3
    That is, it functions, though meaninglessly: "The poll() function shall support regular files... Regular files shall always poll TRUE for reading and writing." http://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. – mkj Nov 08 '11 at 22:35
  • 17
    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. – Rahly Jun 18 '17 at 23:25
  • 2
    @Rahly 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. –  Jun 19 '17 at 00:09
  • 4
    @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. – Rahly Jun 19 '17 at 00:18
  • 2
    In [this repo it is said](https://github.com/littledan/linux-aio/issues/2) 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? – nh2 May 14 '18 at 01:01
  • 1
    @nh2 I'd say that document is wrong. https://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. –  May 14 '18 at 04:16
  • 1
    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"*. – CodeClown42 Feb 02 '22 at 16:04
20

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
osgx
  • 90,338
  • 53
  • 357
  • 513