Menu
▾
▴
#1353 curl_multi_socket_action in edge-triggered mode
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.
libcurl already works as alternative (1) or should be. Edge-triggered is what most event libraries do and libcurl has been used fine by many different ones.
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.
I would still claim that libcurl should already do this fine and if it isn't there's a bug and not a feature-request.
Could you move this to bugs? Or I have to repost everything?
Ticket moved from /p/curl/feature-requests/77/
What if you make lib/transfer.c:data_pending() always return TRUE ?
No response. Closing.