curl_multi_timeout() is really not recommended with curl_multi_socket()-based

\fIcurl_multi_setopt(3)\fP. They update the status with changes since the

previous time this function was called.

To force libcurl to (re-)check all its internal sockets and transfers instead

of just a single one, you call \fBcurl_multi_socket_all(3)\fP. This is

typically done as the first function call before the application has any

knowledge about what sockets libcurl uses.

Applications should call \fBcurl_multi_timeout(3)\fP to figure out how long to

wait for socket actions \- at most \- before doing the timeout action: call

the \fBcurl_multi_socket(3)\fP function with the \fBsockfd\fP argument set to

CURL_SOCKET_TIMEOUT.

Force libcurl to (re-)check all its internal sockets and transfers instead of

just a single one by calling \fBcurl_multi_socket_all(3)\fP. This is typically

done as the first function call before the application has any knowledge about

what sockets libcurl uses.

Get the timeout time - how long to wait for socket actions at most before

doing the timeout action: call the \fBcurl_multi_socket(3)\fP function with

the \fBsockfd\fP argument set to CURL_SOCKET_TIMEOUT, by setting the

\fICURLMOPT_TIMERFUNCTION\fP option with \fIcurl_multi_setopt(3)\fP. You can

also use the \fIcurl_multi_timeout(3)\fP function to poll the value at any

given time, but for an event-based system using the callback is far better

than relying on polling the timeout value.

Usage of \fIcurl_multi_socket(3)\fP is depricated, whereas the function is

equivalent to \fIcurl_multi_socket_action(3)\fP, when \fBev_bitmask\fP is set