You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are several issues introduced by minio#29
When running an application that is rarely restarted, that links to this
sdk I encountered hangs inside of the select() call inside of http.c
multiple times, that required a restart of the application.
Looking into the man pages of curl, it is quite obvious, that the usage of select
is a bad idea here.
On one hand, the requests.fdset() call may return no
filedescriptors, if there is currently nothing to wait for.
(https://curl.se/libcurl/c/curl_multi_fdset.html)
when fdset() returns no filedescriptors, maxfd is set to -1.
this leads to a select call, that has nfds set to 0 and a disabled
timeout. -> this leads to an infinite select() until either the program
is terminated or a signal is received.
On the other hand, if your application is running for some time, new
sockets may have filedescriptors larger than FD_SETSIZE (1024),
according to the docs (https://curl.se/libcurl/c/curl_multi_fdset.html),
fdset does not return any filedescriptors in that case, which leads to
the infinite select() again.
There are two possible solutions to this:
1. waiting for this PR to be merged: jpbarrette/curlpp#173
- Use the poll() or wait() call from there
2. revert to the Easy API again.
- If I understand it correctly the only reason for using the Multi
API was to be able to abort transfers inside of the ResponseCallback,
but that was implemented incorrectly anyway.
Currently the request is removed by requests.remove(request) inside
of the ResponseCallback, which is forbidden by:
'It is fine to remove a handle at any time during a transfer, just
not from within any libcurl callback function.'
(https://curl.se/libcurl/c/curl_multi_remove_handle.html)
Due to these reasons I propose to revert back to the Easy API.
To keep the possibility to abort a running request, CURL_WRITEFUNC_ERROR
is returned at the corresponding locations inside of the
ResponseCallback() function.
0 commit comments