ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/AnyEvent/lib/AnyEvent/Handle.pm
(Generate patch)

Comparing AnyEvent/lib/AnyEvent/Handle.pm (file contents):
Revision 1.99 by root, Thu Oct 23 02:41:00 2008 UTC vs.
Revision 1.112 by root, Wed Jan 21 06:01:35 2009 UTC

14 14
15AnyEvent::Handle - non-blocking I/O on file handles via AnyEvent 15AnyEvent::Handle - non-blocking I/O on file handles via AnyEvent
16 16
17=cut 17=cut
18 18
19our $VERSION = 4.3; 19our $VERSION = 4.331;
20 20
21=head1 SYNOPSIS 21=head1 SYNOPSIS
22 22
23 use AnyEvent; 23 use AnyEvent;
24 use AnyEvent::Handle; 24 use AnyEvent::Handle;
27 27
28 my $handle = 28 my $handle =
29 AnyEvent::Handle->new ( 29 AnyEvent::Handle->new (
30 fh => \*STDIN, 30 fh => \*STDIN,
31 on_eof => sub { 31 on_eof => sub {
32 $cv->broadcast; 32 $cv->send;
33 }, 33 },
34 ); 34 );
35 35
36 # send some request line 36 # send some request line
37 $handle->push_write ("getinfo\015\012"); 37 $handle->push_write ("getinfo\015\012");
84Set the callback to be called when an end-of-file condition is detected, 84Set the callback to be called when an end-of-file condition is detected,
85i.e. in the case of a socket, when the other side has closed the 85i.e. in the case of a socket, when the other side has closed the
86connection cleanly. 86connection cleanly.
87 87
88For sockets, this just means that the other side has stopped sending data, 88For sockets, this just means that the other side has stopped sending data,
89you can still try to write data, and, in fact, one can return from the eof 89you can still try to write data, and, in fact, one can return from the EOF
90callback and continue writing data, as only the read part has been shut 90callback and continue writing data, as only the read part has been shut
91down. 91down.
92 92
93While not mandatory, it is I<highly> recommended to set an eof callback, 93While not mandatory, it is I<highly> recommended to set an EOF callback,
94otherwise you might end up with a closed socket while you are still 94otherwise you might end up with a closed socket while you are still
95waiting for data. 95waiting for data.
96 96
97If an EOF condition has been detected but no C<on_eof> callback has been 97If an EOF condition has been detected but no C<on_eof> callback has been
98set, then a fatal error will be raised with C<$!> set to <0>. 98set, then a fatal error will be raised with C<$!> set to <0>.
255You can also provide your own TLS connection object, but you have 255You can also provide your own TLS connection object, but you have
256to make sure that you call either C<Net::SSLeay::set_connect_state> 256to make sure that you call either C<Net::SSLeay::set_connect_state>
257or C<Net::SSLeay::set_accept_state> on it before you pass it to 257or C<Net::SSLeay::set_accept_state> on it before you pass it to
258AnyEvent::Handle. 258AnyEvent::Handle.
259 259
260B<IMPORTANT:> since Net::SSLeay "objects" are really only integers,
261passing in the wrong integer will lead to certain crash. This most often
262happens when one uses a stylish C<< tls => 1 >> and is surprised about the
263segmentation fault.
264
260See the C<< ->starttls >> method for when need to start TLS negotiation later. 265See the C<< ->starttls >> method for when need to start TLS negotiation later.
261 266
262=item tls_ctx => $ssl_ctx 267=item tls_ctx => $ssl_ctx
263 268
264Use the given C<Net::SSLeay::CTX> object to create the new TLS connection 269Use the given C<Net::SSLeay::CTX> object to create the new TLS connection
326 331
327 $! = $errno; 332 $! = $errno;
328 333
329 if ($self->{on_error}) { 334 if ($self->{on_error}) {
330 $self->{on_error}($self, $fatal); 335 $self->{on_error}($self, $fatal);
331 } else { 336 } elsif ($self->{fh}) {
332 Carp::croak "AnyEvent::Handle uncaught error: $!"; 337 Carp::croak "AnyEvent::Handle uncaught error: $!";
333 } 338 }
334} 339}
335 340
336=item $fh = $handle->fh 341=item $fh = $handle->fh
374} 379}
375 380
376=item $handle->autocork ($boolean) 381=item $handle->autocork ($boolean)
377 382
378Enables or disables the current autocork behaviour (see C<autocork> 383Enables or disables the current autocork behaviour (see C<autocork>
379constructor argument). 384constructor argument). Changes will only take effect on the next write.
380 385
381=cut 386=cut
387
388sub autocork {
389 $_[0]{autocork} = $_[1];
390}
382 391
383=item $handle->no_delay ($boolean) 392=item $handle->no_delay ($boolean)
384 393
385Enables or disables the C<no_delay> setting (see constructor argument of 394Enables or disables the C<no_delay> setting (see constructor argument of
386the same name for details). 395the same name for details).
1135 } 1144 }
1136}; 1145};
1137 1146
1138=item json => $cb->($handle, $hash_or_arrayref) 1147=item json => $cb->($handle, $hash_or_arrayref)
1139 1148
1140Reads a JSON object or array, decodes it and passes it to the callback. 1149Reads a JSON object or array, decodes it and passes it to the
1150callback. When a parse error occurs, an C<EBADMSG> error will be raised.
1141 1151
1142If a C<json> object was passed to the constructor, then that will be used 1152If a C<json> object was passed to the constructor, then that will be used
1143for the final decode, otherwise it will create a JSON coder expecting UTF-8. 1153for the final decode, otherwise it will create a JSON coder expecting UTF-8.
1144 1154
1145This read type uses the incremental parser available with JSON version 1155This read type uses the incremental parser available with JSON version
1162 my $rbuf = \$self->{rbuf}; 1172 my $rbuf = \$self->{rbuf};
1163 1173
1164 my $json = $self->{json} ||= JSON->new->utf8; 1174 my $json = $self->{json} ||= JSON->new->utf8;
1165 1175
1166 sub { 1176 sub {
1177 eval {
1167 my $ref = $json->incr_parse ($self->{rbuf}); 1178 my $ref = $json->incr_parse ($self->{rbuf});
1168 1179
1169 if ($ref) { 1180 if ($ref) {
1181 $self->{rbuf} = $json->incr_text;
1182 $json->incr_text = "";
1183 $cb->($self, $ref);
1184
1185 1
1186 } else {
1187 $self->{rbuf} = "";
1188 ()
1189 }
1190
1191 1
1192 } or do {
1193 # error case
1194 $json->incr_skip;
1195
1170 $self->{rbuf} = $json->incr_text; 1196 $self->{rbuf} = $json->incr_text;
1171 $json->incr_text = ""; 1197 $json->incr_text = "";
1172 $cb->($self, $ref);
1173 1198
1174 1 1199 $self->_error (&Errno::EBADMSG);
1175 } else {
1176 $self->{rbuf} = "";
1177 ()
1178 } 1200 };
1179 } 1201 }
1180}; 1202};
1181 1203
1182=item storable => $cb->($handle, $ref) 1204=item storable => $cb->($handle, $ref)
1183 1205
1371sub starttls { 1393sub starttls {
1372 my ($self, $ssl, $ctx) = @_; 1394 my ($self, $ssl, $ctx) = @_;
1373 1395
1374 require Net::SSLeay; 1396 require Net::SSLeay;
1375 1397
1376 Carp::croak "it is an error to call starttls more than once on an Anyevent::Handle object" 1398 Carp::croak "it is an error to call starttls more than once on an AnyEvent::Handle object"
1377 if $self->{tls}; 1399 if $self->{tls};
1378 1400
1379 if ($ssl eq "accept") { 1401 if ($ssl eq "accept") {
1380 $ssl = Net::SSLeay::new ($ctx || TLS_CTX ()); 1402 $ssl = Net::SSLeay::new ($ctx || TLS_CTX ());
1381 Net::SSLeay::set_accept_state ($ssl); 1403 Net::SSLeay::set_accept_state ($ssl);
1472 } 1494 }
1473} 1495}
1474 1496
1475=item $handle->destroy 1497=item $handle->destroy
1476 1498
1477Shut's down the handle object as much as possible - this call ensures that 1499Shuts down the handle object as much as possible - this call ensures that
1478no further callbacks will be invoked and resources will be freed as much 1500no further callbacks will be invoked and resources will be freed as much
1479as possible. You must not call any methods on the object afterwards. 1501as possible. You must not call any methods on the object afterwards.
1502
1503Normally, you can just "forget" any references to an AnyEvent::Handle
1504object and it will simply shut down. This works in fatal error and EOF
1505callbacks, as well as code outside. It does I<NOT> work in a read or write
1506callback, so when you want to destroy the AnyEvent::Handle object from
1507within such an callback. You I<MUST> call C<< ->destroy >> explicitly in
1508that case.
1480 1509
1481The handle might still linger in the background and write out remaining 1510The handle might still linger in the background and write out remaining
1482data, as specified by the C<linger> option, however. 1511data, as specified by the C<linger> option, however.
1483 1512
1484=cut 1513=cut
1529 1558
1530 1559
1531=head1 NONFREQUENTLY ASKED QUESTIONS 1560=head1 NONFREQUENTLY ASKED QUESTIONS
1532 1561
1533=over 4 1562=over 4
1563
1564=item I C<undef> the AnyEvent::Handle reference inside my callback and
1565still get further invocations!
1566
1567That's because AnyEvent::Handle keeps a reference to itself when handling
1568read or write callbacks.
1569
1570It is only safe to "forget" the reference inside EOF or error callbacks,
1571from within all other callbacks, you need to explicitly call the C<<
1572->destroy >> method.
1573
1574=item I get different callback invocations in TLS mode/Why can't I pause
1575reading?
1576
1577Unlike, say, TCP, TLS connections do not consist of two independent
1578communication channels, one for each direction. Or put differently. The
1579read and write directions are not independent of each other: you cannot
1580write data unless you are also prepared to read, and vice versa.
1581
1582This can mean than, in TLS mode, you might get C<on_error> or C<on_eof>
1583callback invocations when you are not expecting any read data - the reason
1584is that AnyEvent::Handle always reads in TLS mode.
1585
1586During the connection, you have to make sure that you always have a
1587non-empty read-queue, or an C<on_read> watcher. At the end of the
1588connection (or when you no longer want to use it) you can call the
1589C<destroy> method.
1534 1590
1535=item How do I read data until the other side closes the connection? 1591=item How do I read data until the other side closes the connection?
1536 1592
1537If you just want to read your data into a perl scalar, the easiest way 1593If you just want to read your data into a perl scalar, the easiest way
1538to achieve this is by setting an C<on_read> callback that does nothing, 1594to achieve this is by setting an C<on_read> callback that does nothing,
1548 1604
1549The reason to use C<on_error> is that TCP connections, due to latencies 1605The reason to use C<on_error> is that TCP connections, due to latencies
1550and packets loss, might get closed quite violently with an error, when in 1606and packets loss, might get closed quite violently with an error, when in
1551fact, all data has been received. 1607fact, all data has been received.
1552 1608
1553It is usually better to use acknowledgements when transfering data, 1609It is usually better to use acknowledgements when transferring data,
1554to make sure the other side hasn't just died and you got the data 1610to make sure the other side hasn't just died and you got the data
1555intact. This is also one reason why so many internet protocols have an 1611intact. This is also one reason why so many internet protocols have an
1556explicit QUIT command. 1612explicit QUIT command.
1557
1558 1613
1559=item I don't want to destroy the handle too early - how do I wait until 1614=item I don't want to destroy the handle too early - how do I wait until
1560all data has been written? 1615all data has been written?
1561 1616
1562After writing your last bits of data, set the C<on_drain> callback 1617After writing your last bits of data, set the C<on_drain> callback
1568 $handle->on_drain (sub { 1623 $handle->on_drain (sub {
1569 warn "all data submitted to the kernel\n"; 1624 warn "all data submitted to the kernel\n";
1570 undef $handle; 1625 undef $handle;
1571 }); 1626 });
1572 1627
1573=item I get different callback invocations in TLS mode/Why can't I pause
1574reading?
1575
1576Unlike, say, TCP, TLS conenctions do not consist of two independent
1577communication channels, one for each direction. Or put differently. the
1578read and write directions are not independent of each other: you cannot
1579write data unless you are also prepared to read, and vice versa.
1580
1581This can mean than, in TLS mode, you might get C<on_error> or C<on_eof>
1582callback invocations when you are not expecting any read data - the reason
1583is that AnyEvent::Handle always reads in TLS mode.
1584
1585During the connection, you have to make sure that you always have a
1586non-empty read-queue, or an C<on_read> watcher. At the end of the
1587connection (or when you no longer want to use it) you can call the
1588C<destroy> method.
1589
1590=back 1628=back
1591 1629
1592 1630
1593=head1 SUBCLASSING AnyEvent::Handle 1631=head1 SUBCLASSING AnyEvent::Handle
1594 1632

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines