mirror of
https://github.com/moparisthebest/curl
synced 2024-12-21 23:58:49 -05:00
better formatting of functions to get better links in the web version
This commit is contained in:
parent
4ebf4f6e55
commit
237ec68b0e
@ -40,29 +40,29 @@ and setup the appropriate options for each easy handle, as outlined in the
|
||||
\fIlibcurl(3)\fP man page, using \fIcurl_easy_setopt(3)\fP.
|
||||
|
||||
When the easy handle is setup for a transfer, then instead of using
|
||||
\fIcurl_easy_perform\fP (as when using the easy interface for transfers), you
|
||||
should instead add the easy handle to the multi handle using
|
||||
\fIcurl_easy_add_handl\fP. The multi handle is sometimes referred to as a
|
||||
\fIcurl_easy_perform(3)\fP (as when using the easy interface for transfers),
|
||||
you should instead add the easy handle to the multi handle using
|
||||
\fIcurl_easy_add_handle(3)\fP. The multi handle is sometimes referred to as a
|
||||
\'multi stack\' because of the fact that it may hold a large amount of easy
|
||||
handles.
|
||||
|
||||
Should you change your mind, the easy handle is again removed from the multi
|
||||
stack using \fIcurl_multi_remove_handle\fP. Once removed from the multi
|
||||
stack using \fIcurl_multi_remove_handle(3)\fP. Once removed from the multi
|
||||
handle, you can again use other easy interface functions like
|
||||
\fIcurl_easy_perform\fP on the handle or whatever you think is necessary.
|
||||
|
||||
Adding the easy handle to the multi handle does not start the transfer.
|
||||
Remember that one of the main ideas with this interface is to let your
|
||||
application drive. You drive the transfers by invoking
|
||||
\fIcurl_multi_perform\fP. libcurl will then transfer data if there is anything
|
||||
available to transfer. It'll use the callbacks and everything else you have
|
||||
setup in the individual easy handles. It'll transfer data on all current
|
||||
transfers in the multi stack that are ready to transfer anything. It may be
|
||||
all, it may be none.
|
||||
\fIcurl_multi_perform(3)\fP. libcurl will then transfer data if there is
|
||||
anything available to transfer. It'll use the callbacks and everything else
|
||||
you have setup in the individual easy handles. It'll transfer data on all
|
||||
current transfers in the multi stack that are ready to transfer anything. It
|
||||
may be all, it may be none.
|
||||
|
||||
Your application can acquire knowledge from libcurl when it would like to get
|
||||
invoked to transfer data, so that you don't have to busy-loop and call that
|
||||
\fIcurl_multi_perform\fP like crazy. \fIcurl_multi_fdset\fP offers an
|
||||
\fIcurl_multi_perform(3)\fP like crazy. \fIcurl_multi_fdset(3)\fP offers an
|
||||
interface using which you can extract fd_sets from libcurl to use in select()
|
||||
or poll() calls in order to get to know when the transfers in the multi stack
|
||||
might need attention. This also makes it very easy for your program to wait
|
||||
@ -70,30 +70,30 @@ for input on your own private file descriptors at the same time or perhaps
|
||||
timeout every now and then, should you want that.
|
||||
|
||||
A little note here about the return codes from the multi functions, and
|
||||
especially the \fIcurl_multi_perform\fP: if you receive
|
||||
especially the \fIcurl_multi_perform(3)\fP: if you receive
|
||||
\fICURLM_CALL_MULTI_PERFORM\fP, this basicly means that you should call
|
||||
\fIcurl_multi_perform\fP again, before you select() on more actions. You don't
|
||||
have to do it immediately, but the return code means that libcurl may have
|
||||
more data available to return or that there may be more data to send off
|
||||
before it is "satisfied".
|
||||
|
||||
\fIcurl_multi_perform\fP stores the number of still running transfers in one
|
||||
of its input arguments, and by reading that you can figure out when all the
|
||||
transfers in the multi handles are done. 'done' does not mean successful. One
|
||||
or more of the transfers may have failed. Tracking when this number changes,
|
||||
you know when one or more transfers are done.
|
||||
\fIcurl_multi_perform(3)\fP stores the number of still running transfers in
|
||||
one of its input arguments, and by reading that you can figure out when all
|
||||
the transfers in the multi handles are done. 'done' does not mean
|
||||
successful. One or more of the transfers may have failed. Tracking when this
|
||||
number changes, you know when one or more transfers are done.
|
||||
|
||||
To get information about completed transfers, to figure out success or not and
|
||||
similar, \fIcurl_multi_info_read\fP should be called. It can return a message
|
||||
about a current or previous transfer. Repeated invokes of the function get
|
||||
more messages until the message queue is empty. The information you receive
|
||||
there includes an easy handle pointer which you may use to identify which easy
|
||||
handle the information regards.
|
||||
similar, \fIcurl_multi_info_read(3)\fP should be called. It can return a
|
||||
message about a current or previous transfer. Repeated invokes of the function
|
||||
get more messages until the message queue is empty. The information you
|
||||
receive there includes an easy handle pointer which you may use to identify
|
||||
which easy handle the information regards.
|
||||
|
||||
When all transfers in the multi stack are done, cleanup the multi handle with
|
||||
\fIcurl_multi_cleanup\fP. Be careful and please note that you \fBMUST\fP
|
||||
invoke separate \fIcurl_easy_cleanup\fP calls on every single easy handle to
|
||||
clean them up properly.
|
||||
\fIcurl_multi_cleanup(3)\fP. Be careful and please note that you \fBMUST\fP
|
||||
invoke separate \fIcurl_easy_cleanup(3)\fP calls on every single easy handle
|
||||
to clean them up properly.
|
||||
|
||||
If you want to re-use an easy handle that was added to the multi handle for
|
||||
transfer, you must first remove it from the multi stack and then re-add it
|
||||
|
Loading…
Reference in New Issue
Block a user