Re: [PATCH 1/1] eventfd: implementation of EFD_MASK flag

From: Martin Sustrik
Date: Fri Feb 08 2013 - 21:40:43 EST

Hi Eric,

On 08/02/13 23:21, Eric Wong wrote:
Martin Sustrik<sustrik@xxxxxxxxxx> wrote:
On 07/02/13 23:44, Andrew Morton wrote:
That's a nice changelog but it omitted a critical thing: why do you
think the kernel needs this feature? What's the value and use case for
being able to poll these descriptors?

To address the question, I've written down detailed description of
the challenges of the network protocol development in user space and
how the proposed feature addresses the problems.

It's too long to fit into ChangeLog, but it may be worth reading
when trying to judge the merit of the patch.

It can be found here:

Using one eventfd per userspace socket still seems a bit wasteful.

Wasteful in what sense? Occupying a slot in file descriptor table? That's the price for having the socket uniquely identified by the fd.

Couldn't you use a single pipe for all sockets and write the efd_mask to
the pipe for each socket?

A read from the pipe would behave like epoll_wait.

You might need to use one-shot semantics; but that's probably
the easiest thing in multithreaded apps anyways.

Having multiple sockets represented by a single eventfd. how would you distinguish where did individual events came from?

struct pollfd pfd;
poll (pfd, 1, -1);
if (pfd.revents & POLLIN) /* Incoming data on which socket? */

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at