On Tue, 17 Jul 2018, Richard W.M. Jones wrote:
I've written my Curl_handler.connecting callback so it returns CURLE_AGAIN
if the socket would block. However this causes the whole connection to fail
(see debug trace at end).
If I change the callback so it loops until *done == TRUE then it works, but
I think this is just blocking behaviour.
I can see the PROTOCONNECT case in lib/multi.c doesn't deal with CURLE_AGAIN
at all.
Should I return CURLE_OK (and *done == FALSE) in the blocking case? What is
the point of CURLE_AGAIN?
Originally I thought using CURLE_AGAIN in similar style how common network
functions work was a good idea (so that error code was then introduced), but I
later figured out that the code turns out nicer if we don't consider the
"would block" situation as an error so we've switched away from using that
error code. I can in fact not see any traces left of code using it... We
should probably mark it as deprecated somehow.
libcurl was never built to support new custom handlers to be added very
flexibly so I'm sure there are cases where if none of the existing handlers do
something, there's no code to handle that which could be interesting when
adding a new handler with potentially new code paths. We'll just have to try
to fix the issues as we run into them.
--
/ daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
