~ubuntu-branches/ubuntu/vivid/curl/vivid

« back to all changes in this revision

Viewing changes to docs/libcurl/curl_multi_socket.3

  • Committer: Bazaar Package Importer
  • Author(s): Andreas Schuldei
  • Date: 2009-04-02 23:35:45 UTC
  • mto: (1.2.1 upstream) (3.2.3 sid)
  • mto: This revision was merged to the branch mainline in revision 38.
  • Revision ID: james.westby@ubuntu.com-20090402233545-geixkwhe3izccjt7
Tags: upstream-7.19.4
ImportĀ upstreamĀ versionĀ 7.19.4

Show diffs side-by-side

added added

removed removed

Lines of Context:
1
 
.\" $Id: curl_multi_socket.3,v 1.13 2008-05-24 19:19:49 bagder Exp $
 
1
.\" $Id: curl_multi_socket.3,v 1.15 2008-12-28 21:56:56 bagder Exp $
2
2
.\"
3
3
.TH curl_multi_socket 3 "9 Jul 2006" "libcurl 7.16.0" "libcurl Manual"
4
4
.SH NAME
10
10
CURLMcode curl_multi_socket_action(CURLM * multi_handle, 
11
11
                                   curl_socket_t sockfd, int ev_bitmask,
12
12
                                   int *running_handles);
 
13
.fi
13
14
 
 
15
.B "Now deprecated versions:"
 
16
.nf
14
17
CURLMcode curl_multi_socket(CURLM * multi_handle, curl_socket_t sockfd,
15
18
                            int *running_handles);
16
19
 
20
23
.SH DESCRIPTION
21
24
Alternative versions of \fIcurl_multi_perform(3)\fP that allows the
22
25
application to pass in the file descriptor/socket that has been detected to
23
 
have \&"action" on it and let libcurl perform. This allows libcurl to not have
24
 
to scan through all possible file descriptors to check for action. When the
25
 
application has detected action on a socket handled by libcurl, it should call
26
 
\fIcurl_multi_socket_action(3)\fP with the \fBsockfd\fP argument set to the
27
 
socket with the action. When the events on a socket are known, they can be
28
 
passed as an events bitmask \fBev_bitmask\fP by first setting \fBev_bitmask\fP
29
 
to 0, and then adding using bitwise OR (|) any combination of events to be
30
 
chosen from CURL_CSELECT_IN, CURL_CSELECT_OUT or CURL_CSELECT_ERR. When the
31
 
events on a socket are unknown, pass 0 instead, and libcurl will test the
32
 
descriptor internally.
33
 
 
34
 
At return, the int \fBrunning_handles\fP points to will contain the number of
35
 
still running easy handles within the multi handle. When this number reaches
36
 
zero, all transfers are complete/done. Note that when you call
 
26
have \&"action" on it and let libcurl perform. This lets libcurl avoid having
 
27
to scan through all possible file descriptors to check for action.
 
28
 
 
29
When the application has detected action on a socket handled by libcurl, it
 
30
should call \fIcurl_multi_socket_action(3)\fP with the \fBsockfd\fP argument
 
31
set to the socket with the action. When the events on a socket are known, they
 
32
can be passed as an events bitmask \fBev_bitmask\fP by first setting
 
33
\fBev_bitmask\fP to 0, and then adding using bitwise OR (|) any combination of
 
34
events to be chosen from CURL_CSELECT_IN, CURL_CSELECT_OUT or
 
35
CURL_CSELECT_ERR. When the events on a socket are unknown, pass 0 instead, and
 
36
libcurl will test the descriptor internally.
 
37
 
 
38
At return, the integer \fBrunning_handles\fP points to will contain the number
 
39
of still running easy handles within the multi handle. When this number
 
40
reaches zero, all transfers are complete/done. Note that when you call
37
41
\fIcurl_multi_socket_action(3)\fP on a specific socket and the counter
38
42
decreases by one, it DOES NOT necessarily mean that this exact socket/transfer
39
43
is the one that completed. Use \fIcurl_multi_info_read(3)\fP to figure out
40
44
which easy handle that completed.
41
45
 
42
 
The curl_multi_socket functions inform the application about updates in the
43
 
socket (file descriptor) status by doing none, one or multiple calls to the
44
 
socket callback function set with the CURLMOPT_SOCKETFUNCTION option to
45
 
\fIcurl_multi_setopt(3)\fP. They update the status with changes since the
46
 
previous time this function was called.
 
46
The \fBcurl_multi_socket_action(3)\fP functions inform the application about
 
47
updates in the socket (file descriptor) status by doing none, one, or multiple
 
48
calls to the socket callback function set with the CURLMOPT_SOCKETFUNCTION
 
49
option to \fIcurl_multi_setopt(3)\fP. They update the status with changes
 
50
since the previous time the callback was called.
 
51
 
 
52
Get the timeout time by setting the \fICURLMOPT_TIMERFUNCTION\fP option with
 
53
\fIcurl_multi_setopt(3)\fP. Your application will then get called with
 
54
information on how long to wait for socket actions at most before doing the
 
55
timeout action: call the \fBcurl_multi_socket_action(3)\fP function with the
 
56
\fBsockfd\fP argument set to CURL_SOCKET_TIMEOUT. You can also use the
 
57
\fIcurl_multi_timeout(3)\fP function to poll the value at any given time, but
 
58
for an event-based system using the callback is far better than relying on
 
59
polling the timeout value.
 
60
 
 
61
Usage of \fIcurl_multi_socket(3)\fP is deprecated, whereas the function is
 
62
equivalent to \fIcurl_multi_socket_action(3)\fP with \fBev_bitmask\fP set to
 
63
0.
47
64
 
48
65
Force libcurl to (re-)check all its internal sockets and transfers instead of
49
66
just a single one by calling \fBcurl_multi_socket_all(3)\fP. Note that there
50
 
should rarely be reasons to use this function!
51
 
 
52
 
Get the timeout time - how long to wait for socket actions at most before
53
 
doing the timeout action: call the \fBcurl_multi_socket(3)\fP function with
54
 
the \fBsockfd\fP argument set to CURL_SOCKET_TIMEOUT, by setting the
55
 
\fICURLMOPT_TIMERFUNCTION\fP option with \fIcurl_multi_setopt(3)\fP. You can
56
 
also use the \fIcurl_multi_timeout(3)\fP function to poll the value at any
57
 
given time, but for an event-based system using the callback is far better
58
 
than relying on polling the timeout value.
59
 
 
60
 
Usage of \fIcurl_multi_socket(3)\fP is deprecated, whereas the function is
61
 
equivalent to \fIcurl_multi_socket_action(3)\fP, when \fBev_bitmask\fP is set 
62
 
to 0.
63
 
 
 
67
should not be any reason to use this function!
64
68
.SH "CALLBACK DETAILS"
65
69
 
66
70
The socket \fBcallback\fP function uses a prototype like this
107
111
.SH "RETURN VALUE"
108
112
CURLMcode type, general libcurl multi interface error code.
109
113
 
110
 
If you receive \fICURLM_CALL_MULTI_PERFORM\fP, this basically means that you
111
 
should call \fIcurl_multi_socket(3)\fP again, before you wait for more actions
112
 
on libcurl's sockets. You don't have to do it immediately, but the return code
113
 
means that libcurl may have more data available to return or that there may be
114
 
more data to send off before it is "satisfied".
115
 
 
116
 
NOTE that this only returns errors etc regarding the whole multi stack. There
117
 
might still have occurred problems on individual transfers even when this
118
 
function returns OK.
 
114
Legacy: If you receive \fICURLM_CALL_MULTI_PERFORM\fP, this basically means
 
115
that you should call \fIcurl_multi_socket(3)\fP again, before you wait for
 
116
more actions on libcurl's sockets. You don't have to do it immediately, but
 
117
the return code means that libcurl may have more data available to return or
 
118
that there may be more data to send off before it is "satisfied".
 
119
 
 
120
In modern libcurls, \fICURLM_CALL_MULTI_PERFORM\fP or
 
121
\fICURLM_CALL_MULTI_SOKCET\fP should not be returned and no application needs
 
122
to care about them.
 
123
 
 
124
NOTE that the return code is for the whole multi stack. Problems still might have
 
125
occurred on individual transfers even when one of these functions
 
126
return OK.
119
127
.SH "TYPICAL USAGE"
120
128
1. Create a multi handle
121
129
 
139
147
 
140
148
8. Go back to step 6.
141
149
.SH AVAILABILITY
142
 
This function was added in libcurl 7.15.4, although deemed stable since
 
150
This function was added in libcurl 7.15.4, and is deemed stable since
143
151
7.16.0.
144
152
 
145
153
\fIcurl_multi_socket(3)\fP is deprecated, use