Profiling an application that uses the `curl_multi_socket_action`
interface, I noticed that the writeable-socket callback for my event
framework (libevent in this case) was being invoked many times when
issuing HTTP GET requests. I quickly determined that this stems from
configuring libevent for level-triggered & persistent socket events;
libcurl registers for INOUT mode while sending the request and
libevent will repeatedly raise writeable socket events until write
registration is removed with another socket callback with
`CURL_POLL_IN` (when waiting for the response).

One wait to avoid these callbacks would be to set my events to be
edge-triggered. I haven't read the multi implementation in sufficient
detail to know if this is safe, however. If the underlying socket
write returns EAGAIN while writing the the HTTP GET request, will
libcurl invoke the socket callback to indicate its interest in
writeable-socket notifications? Cursory reading suggests that it will
not; it looks to me like determination of when to invoke the callback
is based on the phase of the request in `singlesocket()`, and that the
`Curl_sh_entry.action` field is not updated outside of that method.

Perhaps somebody with more familiarity can clarify or point out where
I've gone wrong? For many concurrent transfers I am burning
considerable CPU time servicing useless writeable-socket events and
would love to avoid them.

Best,

--nate
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-01-27