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
