Add support for eventfd-like mechanism

[sigiesec]

To avoid the need for TCP loopback connections, an eventfd-like mechanism would be great that could be used with wepoll.

See existing work in truebiker@32442e4

[piscisaureus]

I could maybe do that, but please consider:

1. I'm trying to limit the scope of wepoll as much as possible (that's why there are no abstractions for e.g. socketpair() inside wepoll, even if that'd be quite useful). Therefore I am also not going to add a complete eventfd API to wepoll.
2. APIs that do not exist on linux should be clearly marked as such. (I realize that epoll_close is currently in violation of this rule.)
3. So maybe I could add something like the following:

   int epoll_post(HANDLE epfd, struct epoll_event* ev);

4. This would post a single, user-specified event to the epoll port.
5. The event would be reported by epoll_wait exactly once.
6. Per consideration (2), should we call the function wepoll_post() or epoll_post_win() ?
7. Per consideration (5), should we mandate that the posted event has the EPOLLONESHOT flag set, or otherwise it fails with EINVAL? Alternatively, EPOLLONESHOT might be implied.

[sigiesec]

Thank you for considering this. At first sight this sounds as if this would be sufficient for the needs within libzmq.

I can totally understand you don't want the scope of wepoll to blur. However, I think this addition cannot be built on top of wepoll, and it would be a significant improvement on Windows where you don't have AF_UNIX.

However, I am somewhat surprised of your mentioning of socketpair. This were another alternative. Would that be possible in theory? I think this could not be built on top of (w)epoll as well, right?

Regarding 6. I personally like wepoll_post slightly more. Should epoll_close be renamed to wepoll_close as well, after some deprecation cycle?

Regarding 7. Requiring setting the flag explicitly is probably safer.

[ghost]

3. So maybe I could add something like the following:

   int epoll_post(HANDLE epfd, struct epoll_event* ev);

This looks great!

6. Per consideration (2), should we call the function wepoll_post() or epoll_post_win() ?

Since we already have epoll_close(), my preference leans towards epoll_post() but I have no strong feelings on the matter. I think it's reasonable for wepoll to provide the exact same API epoll has, and then fill in the gaps with additions like epoll_close() and epoll_post().

7. Per consideration (5), should we mandate that the posted event has the EPOLLONESHOT flag set, or otherwise it fails with EINVAL? Alternatively, EPOLLONESHOT might be implied.

My intuition would be that epoll_post() delivers a completely arbitrary event once - of course it is a "oneshot event" because what else could posting even an EPOLLET or !EPOLLONESHOT event mean?

Since the posted event is an arbitrary, 'simulated' event, mandating special rules around EPOLLONESHOT is not necessary, IMO. If someone is messing around with epoll by simulating events, they probably know what they're doing.

[mickae1]

I'm also interested, what is the status of this request ?