I modified hiperfifo example (see hiperfifo.patch) to use edge-triggered mode. (I also disabled some log messages to make debug trace cleaner.) Then I ran it against my HTTP(S) server: it sends long zeroes file very fast via loopback. I made 4 runs: HTTP or HTTPS, in edge or level triggered mode (later is without EV_ET flag as it is originally). See strace logs attached. In 'edge' cases transfer hangs and I interrupt it with ^C.

The bad thing is that after each epoll_wait() call only single (or two in HTTPS case) recvfrom() call is done. If we choose the first way, there should be a loop exiting on EAGAIN.

Attachment: edge-http.log (20.5 kB; text/plain) edge-https.log (53.8 kB; text/plain) hiperfifo.patch (1.6 kB; text/x-patch) level-http.log (236.4 kB; text/plain) level-https.log (302.1 kB; text/plain)

---
** [feature-requests:#77] Support user's network reactors in edge-triggered mode**
**Status:** pending
**Created:** Wed Apr 02, 2014 07:36 AM UTC by Constantin Baranov
**Last Updated:** Thu Apr 03, 2014 11:05 AM UTC
**Owner:** Daniel Stenberg
An edge-triggered reactor like epoll with EPOLLET flag enabled supposes that at every iteration user (I/O handler) has to drain/fill all buffers to be able to receive next event on the same socket. If you're notified that a socket is writable, you keep writing to it until you get EAGAIN, same for reading.
curl_multi_socket_action() performs single iteration around given socket. To fit in the above mentioned model either one modification is needed:
* curl_multi_socket_action() shall perform as much I/O on given socket as possible without blocking. Easier to implement, but may lead to a starvation of other sockets in the same multi set.
* curl_multi_socket_action() shall return special value (CURLM_CALL_MULTI_PERFORM? or return the 'remaining' (not completely drained) events mask) if it hasn't received EAGAIN yet and thus could be called again without waiting.
The later approach seems better to me, but most likely will require many changes in multi implementation and, even worse, in some protocol implementation like SSL.
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/feature-requests/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.