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.107 by root, Wed Nov 26 06:40:47 2008 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.33;
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>.
326 326
327 $! = $errno; 327 $! = $errno;
328 328
329 if ($self->{on_error}) { 329 if ($self->{on_error}) {
330 $self->{on_error}($self, $fatal); 330 $self->{on_error}($self, $fatal);
331 } else { 331 } elsif ($self->{fh}) {
332 Carp::croak "AnyEvent::Handle uncaught error: $!"; 332 Carp::croak "AnyEvent::Handle uncaught error: $!";
333 } 333 }
334} 334}
335 335
336=item $fh = $handle->fh 336=item $fh = $handle->fh
374} 374}
375 375
376=item $handle->autocork ($boolean) 376=item $handle->autocork ($boolean)
377 377
378Enables or disables the current autocork behaviour (see C<autocork> 378Enables or disables the current autocork behaviour (see C<autocork>
379constructor argument). 379constructor argument). Changes will only take effect on the next write.
380 380
381=cut 381=cut
382
383sub autocork {
384 $_[0]{autocork} = $_[1];
385}
382 386
383=item $handle->no_delay ($boolean) 387=item $handle->no_delay ($boolean)
384 388
385Enables or disables the C<no_delay> setting (see constructor argument of 389Enables or disables the C<no_delay> setting (see constructor argument of
386the same name for details). 390the same name for details).
1371sub starttls { 1375sub starttls {
1372 my ($self, $ssl, $ctx) = @_; 1376 my ($self, $ssl, $ctx) = @_;
1373 1377
1374 require Net::SSLeay; 1378 require Net::SSLeay;
1375 1379
1376 Carp::croak "it is an error to call starttls more than once on an Anyevent::Handle object" 1380 Carp::croak "it is an error to call starttls more than once on an AnyEvent::Handle object"
1377 if $self->{tls}; 1381 if $self->{tls};
1378 1382
1379 if ($ssl eq "accept") { 1383 if ($ssl eq "accept") {
1380 $ssl = Net::SSLeay::new ($ctx || TLS_CTX ()); 1384 $ssl = Net::SSLeay::new ($ctx || TLS_CTX ());
1381 Net::SSLeay::set_accept_state ($ssl); 1385 Net::SSLeay::set_accept_state ($ssl);
1472 } 1476 }
1473} 1477}
1474 1478
1475=item $handle->destroy 1479=item $handle->destroy
1476 1480
1477Shut's down the handle object as much as possible - this call ensures that 1481Shuts 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 1482no further callbacks will be invoked and resources will be freed as much
1479as possible. You must not call any methods on the object afterwards. 1483as possible. You must not call any methods on the object afterwards.
1484
1485Normally, you can just "forget" any references to an AnyEvent::Handle
1486object and it will simply shut down. This works in fatal error and EOF
1487callbacks, as well as code outside. It does I<NOT> work in a read or write
1488callback, so when you want to destroy the AnyEvent::Handle object from
1489within such an callback. You I<MUST> call C<< ->destroy >> explicitly in
1490that case.
1480 1491
1481The handle might still linger in the background and write out remaining 1492The handle might still linger in the background and write out remaining
1482data, as specified by the C<linger> option, however. 1493data, as specified by the C<linger> option, however.
1483 1494
1484=cut 1495=cut
1529 1540
1530 1541
1531=head1 NONFREQUENTLY ASKED QUESTIONS 1542=head1 NONFREQUENTLY ASKED QUESTIONS
1532 1543
1533=over 4 1544=over 4
1545
1546=item I C<undef> the AnyEvent::Handle reference inside my callback and
1547still get further invocations!
1548
1549That's because AnyEvent::Handle keeps a reference to itself when handling
1550read or write callbacks.
1551
1552It is only safe to "forget" the reference inside EOF or error callbacks,
1553from within all other callbacks, you need to explicitly call the C<<
1554->destroy >> method.
1555
1556=item I get different callback invocations in TLS mode/Why can't I pause
1557reading?
1558
1559Unlike, say, TCP, TLS connections do not consist of two independent
1560communication channels, one for each direction. Or put differently. The
1561read and write directions are not independent of each other: you cannot
1562write data unless you are also prepared to read, and vice versa.
1563
1564This can mean than, in TLS mode, you might get C<on_error> or C<on_eof>
1565callback invocations when you are not expecting any read data - the reason
1566is that AnyEvent::Handle always reads in TLS mode.
1567
1568During the connection, you have to make sure that you always have a
1569non-empty read-queue, or an C<on_read> watcher. At the end of the
1570connection (or when you no longer want to use it) you can call the
1571C<destroy> method.
1534 1572
1535=item How do I read data until the other side closes the connection? 1573=item How do I read data until the other side closes the connection?
1536 1574
1537If you just want to read your data into a perl scalar, the easiest way 1575If 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, 1576to achieve this is by setting an C<on_read> callback that does nothing,
1548 1586
1549The reason to use C<on_error> is that TCP connections, due to latencies 1587The 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 1588and packets loss, might get closed quite violently with an error, when in
1551fact, all data has been received. 1589fact, all data has been received.
1552 1590
1553It is usually better to use acknowledgements when transfering data, 1591It is usually better to use acknowledgements when transferring data,
1554to make sure the other side hasn't just died and you got the data 1592to 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 1593intact. This is also one reason why so many internet protocols have an
1556explicit QUIT command. 1594explicit QUIT command.
1557
1558 1595
1559=item I don't want to destroy the handle too early - how do I wait until 1596=item I don't want to destroy the handle too early - how do I wait until
1560all data has been written? 1597all data has been written?
1561 1598
1562After writing your last bits of data, set the C<on_drain> callback 1599After writing your last bits of data, set the C<on_drain> callback
1568 $handle->on_drain (sub { 1605 $handle->on_drain (sub {
1569 warn "all data submitted to the kernel\n"; 1606 warn "all data submitted to the kernel\n";
1570 undef $handle; 1607 undef $handle;
1571 }); 1608 });
1572 1609
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 1610=back
1591 1611
1592 1612
1593=head1 SUBCLASSING AnyEvent::Handle 1613=head1 SUBCLASSING AnyEvent::Handle
1594 1614

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines