2002-03-04 11:09:48 +01:00
|
|
|
.\" $Id$
|
|
|
|
.\"
|
|
|
|
.TH curl_multi_perform 3 "1 March 2002" "libcurl 7.9.5" "libcurl Manual"
|
|
|
|
.SH NAME
|
2002-10-15 10:39:30 +02:00
|
|
|
curl_multi_perform - reads/writes available data from each easy handle
|
2002-03-04 11:09:48 +01:00
|
|
|
.SH SYNOPSIS
|
|
|
|
#include <curl/curl.h>
|
|
|
|
|
|
|
|
CURLMcode curl_multi_perform(CURLM *multi_handle, int *running_handles);
|
|
|
|
.ad
|
|
|
|
.SH DESCRIPTION
|
|
|
|
When the app thinks there's data available for the multi_handle, it should
|
|
|
|
call this function to read/write whatever there is to read or write right
|
|
|
|
now. curl_multi_perform() returns as soon as the reads/writes are done. This
|
|
|
|
function does not require that there actually is any data available for
|
|
|
|
reading or that data can be written, it can be called just in case. It will
|
|
|
|
write the number of handles that still transfer data in the second argument's
|
|
|
|
integer-pointer.
|
2004-10-03 19:38:57 +02:00
|
|
|
|
|
|
|
When you call curl_multi_perform() and the amount of \fIrunning_handles\fP is
|
|
|
|
changed from the previous call (or is less than the amount of easy handles
|
|
|
|
you've added to the multi handle), you know that there is one or more
|
|
|
|
transfers less "running". You can then call \fIcurl_multi_info_read(3)\fP to
|
|
|
|
get information about each individual completed transfer, and that returned
|
|
|
|
info includes CURLcode and more.
|
2002-03-04 11:09:48 +01:00
|
|
|
.SH "RETURN VALUE"
|
|
|
|
CURLMcode type, general libcurl multi interface error code.
|
|
|
|
|
2004-03-24 22:40:45 +01:00
|
|
|
If you receive \fICURLM_CALL_MULTI_PERFORM\fP, this basically means that you
|
2002-12-03 13:40:12 +01:00
|
|
|
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
|
2006-09-21 13:09:54 +02:00
|
|
|
to send off before it is "satisfied". Do note that \fIcurl_multi_perform(3)\fP
|
|
|
|
will return \fICURLM_CALL_MULTI_PERFORM\fP only when it wants to be called
|
2008-12-28 22:56:56 +01:00
|
|
|
again \fBimmediately\fP. When things are fine and there is nothing immediate
|
2006-09-21 13:09:54 +02:00
|
|
|
it wants done, it'll return \fICURLM_OK\fP and you need to wait for \&"action"
|
|
|
|
and then call this function again.
|
2002-12-03 13:40:12 +01:00
|
|
|
|
2008-12-28 22:56:56 +01:00
|
|
|
NOTE that this only returns errors etc regarding the whole multi stack. Problems
|
|
|
|
still might have occurred on individual transfers even when this
|
2006-09-21 13:09:54 +02:00
|
|
|
function returns \fICURLM_OK\fP.
|
2002-03-04 11:09:48 +01:00
|
|
|
.SH "TYPICAL USAGE"
|
2006-01-03 00:32:36 +01:00
|
|
|
Most applications will use \fIcurl_multi_fdset(3)\fP to get the multi_handle's
|
|
|
|
file descriptors, then it'll wait for action on them using \fBselect(3)\fP and
|
|
|
|
as soon as one or more of them are ready, \fIcurl_multi_perform(3)\fP gets
|
2004-03-15 12:37:37 +01:00
|
|
|
called.
|
2002-03-04 11:09:48 +01:00
|
|
|
.SH "SEE ALSO"
|
2004-10-03 19:38:57 +02:00
|
|
|
.BR curl_multi_cleanup "(3), " curl_multi_init "(3), "
|
2006-09-21 13:09:54 +02:00
|
|
|
.BR curl_multi_fdset "(3), " curl_multi_info_read "(3), "
|
|
|
|
.BR libcurl-errors "(3)"
|