CURLMOPT_SOCKETFUNCTION and CURLMOPT_TIMERFUNCTION can't report errors to libcurl #8083
I did this
According to the documentation,
After checking the documentation for the adjacent
Further inspection of the source code indicates the return value of these callbacks is always disregarded:
I expected the following
The documentation is unclear about how the return values from these functions are handled.
Arguably, a reasonable interpretation would expect
At a minimum, the documentation should state that the values are ignored, with possible workarounds - e.g.: how to cancel the easy handle appropriately in the case of
Ideally, the return values should be inspected and handled appropriately.
It is common for
Some state machines rely on appropriate behavior in order to stop / free resources (e.g.: stop and free the poller upon
It is unclear which events are guaranteed to be delivered, even in the presence of errors, so that appropriate resource management can take place without additional custom machinery being implemented (e.g.: garbage collect pollers from dead requests; call
Likewise, it is unclear what's the appropriate follow up for the failed requests, or how to even detect if the request failed due to a callback returning
Should one of these callbacks fail, thus having to report
I'd love to be able to contribute a fix, but I currently don't have the time, nor expertise in
Checked sources for latest head as of this reporting.
Observed on the following build:
Seemingly not OS specific. Observed on
The text was updated successfully, but these errors were encountered:
Thanks for this fine report!
I believe I never implemented any action in the event of an error being returned from these callbacks partly because I couldn't make up my mind on what exactly the correct course of action would be when one of those callbacks return error. That's also why the documentation doesn't say anything about it. Another reason would probably be that applications very rarely actually return error there so this omission has remained ignored/forgotten...
I guess the only sensible way to treat these errors is to immediately cancel the transfer, since a transfer done with an application that is setup to use these callbacks cannot really be handled correctly anymore from that point.
I think perhaps the slightly trickier part with this behavior is that it will take down all currently active transfers but once they're all closed down, it should probably be possible to start over and add new connections to the multi handle again.
I'll try to make a test case for all this...
The callbacks were partially documented to support this. Now the behavior is documented and returning error from either of these callbacks will effectively kill all currently ongoing transfers. Added test 530 to verify Reported-by: Marcelo Juchem Fixes #8083 Closes #....
I've done some testing and had success with the following approach:
I don't believe curl needs to always cancel all transfers, since:
If the application wants to avoid causing all transfers to fail, it can do that by not returning error from the callback and it can then opt to handle it using a work-around as you describe. I don't think that's a way we should encourage though, as it will be complicated and error-prone. The timer is meant to be able to expire many times during a single transfer, and a work-around then needs to replace all of them artificially.
The specific fd is not always unique for one or a subset of transfer, it can also be the name resolving fd for example which is used by (almost) all transfers. So, yes, while we could make libcurl not fail all transfers for socket cb failure, I don't think think it is worth the trouble to support that.