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.114 by root, Wed Jan 21 06:06:22 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 {
1167 my $ref = $json->incr_parse ($self->{rbuf}); 1177 my $ref = eval { $json->incr_parse ($self->{rbuf}) };
1168 1178
1169 if ($ref) { 1179 if ($ref) {
1170 $self->{rbuf} = $json->incr_text; 1180 $self->{rbuf} = $json->incr_text;
1171 $json->incr_text = ""; 1181 $json->incr_text = "";
1172 $cb->($self, $ref); 1182 $cb->($self, $ref);
1173 1183
1174 1 1184 1
1185 } elsif ($@) {
1186 # error case
1187 $json->incr_skip;
1188
1189 $self->{rbuf} = $json->incr_text;
1190 $json->incr_text = "";
1191
1192 $self->_error (&Errno::EBADMSG);
1193
1194 ()
1175 } else { 1195 } else {
1176 $self->{rbuf} = ""; 1196 $self->{rbuf} = "";
1197
1177 () 1198 ()
1178 } 1199 }
1179 } 1200 }
1180}; 1201};
1181 1202
1371sub starttls { 1392sub starttls {
1372 my ($self, $ssl, $ctx) = @_; 1393 my ($self, $ssl, $ctx) = @_;
1373 1394
1374 require Net::SSLeay; 1395 require Net::SSLeay;
1375 1396
1376 Carp::croak "it is an error to call starttls more than once on an Anyevent::Handle object" 1397 Carp::croak "it is an error to call starttls more than once on an AnyEvent::Handle object"
1377 if $self->{tls}; 1398 if $self->{tls};
1378 1399
1379 if ($ssl eq "accept") { 1400 if ($ssl eq "accept") {
1380 $ssl = Net::SSLeay::new ($ctx || TLS_CTX ()); 1401 $ssl = Net::SSLeay::new ($ctx || TLS_CTX ());
1381 Net::SSLeay::set_accept_state ($ssl); 1402 Net::SSLeay::set_accept_state ($ssl);
1472 } 1493 }
1473} 1494}
1474 1495
1475=item $handle->destroy 1496=item $handle->destroy
1476 1497
1477Shut's down the handle object as much as possible - this call ensures that 1498Shuts 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 1499no further callbacks will be invoked and resources will be freed as much
1479as possible. You must not call any methods on the object afterwards. 1500as possible. You must not call any methods on the object afterwards.
1501
1502Normally, you can just "forget" any references to an AnyEvent::Handle
1503object and it will simply shut down. This works in fatal error and EOF
1504callbacks, as well as code outside. It does I<NOT> work in a read or write
1505callback, so when you want to destroy the AnyEvent::Handle object from
1506within such an callback. You I<MUST> call C<< ->destroy >> explicitly in
1507that case.
1480 1508
1481The handle might still linger in the background and write out remaining 1509The handle might still linger in the background and write out remaining
1482data, as specified by the C<linger> option, however. 1510data, as specified by the C<linger> option, however.
1483 1511
1484=cut 1512=cut
1529 1557
1530 1558
1531=head1 NONFREQUENTLY ASKED QUESTIONS 1559=head1 NONFREQUENTLY ASKED QUESTIONS
1532 1560
1533=over 4 1561=over 4
1562
1563=item I C<undef> the AnyEvent::Handle reference inside my callback and
1564still get further invocations!
1565
1566That's because AnyEvent::Handle keeps a reference to itself when handling
1567read or write callbacks.
1568
1569It is only safe to "forget" the reference inside EOF or error callbacks,
1570from within all other callbacks, you need to explicitly call the C<<
1571->destroy >> method.
1572
1573=item I get different callback invocations in TLS mode/Why can't I pause
1574reading?
1575
1576Unlike, say, TCP, TLS connections 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.
1534 1589
1535=item How do I read data until the other side closes the connection? 1590=item How do I read data until the other side closes the connection?
1536 1591
1537If you just want to read your data into a perl scalar, the easiest way 1592If 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, 1593to achieve this is by setting an C<on_read> callback that does nothing,
1548 1603
1549The reason to use C<on_error> is that TCP connections, due to latencies 1604The 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 1605and packets loss, might get closed quite violently with an error, when in
1551fact, all data has been received. 1606fact, all data has been received.
1552 1607
1553It is usually better to use acknowledgements when transfering data, 1608It is usually better to use acknowledgements when transferring data,
1554to make sure the other side hasn't just died and you got the data 1609to 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 1610intact. This is also one reason why so many internet protocols have an
1556explicit QUIT command. 1611explicit QUIT command.
1557
1558 1612
1559=item I don't want to destroy the handle too early - how do I wait until 1613=item I don't want to destroy the handle too early - how do I wait until
1560all data has been written? 1614all data has been written?
1561 1615
1562After writing your last bits of data, set the C<on_drain> callback 1616After writing your last bits of data, set the C<on_drain> callback
1568 $handle->on_drain (sub { 1622 $handle->on_drain (sub {
1569 warn "all data submitted to the kernel\n"; 1623 warn "all data submitted to the kernel\n";
1570 undef $handle; 1624 undef $handle;
1571 }); 1625 });
1572 1626
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 1627=back
1591 1628
1592 1629
1593=head1 SUBCLASSING AnyEvent::Handle 1630=head1 SUBCLASSING AnyEvent::Handle
1594 1631

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines