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.97 by root, Thu Oct 2 11:07:59 2008 UTC vs.
Revision 1.102 by root, Wed Oct 29 14:32:02 2008 UTC

59treatment of characters applies to this module as well. 59treatment of characters applies to this module as well.
60 60
61All callbacks will be invoked with the handle object as their first 61All callbacks will be invoked with the handle object as their first
62argument. 62argument.
63 63
64=head2 SIGPIPE is not handled by this module
65
66SIGPIPE is not handled by this module, so one of the practical
67requirements of using it is to ignore SIGPIPE (C<$SIG{PIPE} =
68'IGNORE'>). At least, this is highly recommend in a networked program: If
69you use AnyEvent::Handle in a filter program (like sort), exiting on
70SIGPIPE is probably the right thing to do.
71
72=head1 METHODS 64=head1 METHODS
73 65
74=over 4 66=over 4
75 67
76=item B<new (%args)> 68=item B<new (%args)>
92Set 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,
93i.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
94connection cleanly. 86connection cleanly.
95 87
96For 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,
97you 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
98callback 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
99down. 91down.
100 92
101While 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,
102otherwise 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
103waiting for data. 95waiting for data.
104 96
105If 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
106set, 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>.
334 326
335 $! = $errno; 327 $! = $errno;
336 328
337 if ($self->{on_error}) { 329 if ($self->{on_error}) {
338 $self->{on_error}($self, $fatal); 330 $self->{on_error}($self, $fatal);
339 } else { 331 } elsif ($self->{fh}) {
340 Carp::croak "AnyEvent::Handle uncaught error: $!"; 332 Carp::croak "AnyEvent::Handle uncaught error: $!";
341 } 333 }
342} 334}
343 335
344=item $fh = $handle->fh 336=item $fh = $handle->fh
1379sub starttls { 1371sub starttls {
1380 my ($self, $ssl, $ctx) = @_; 1372 my ($self, $ssl, $ctx) = @_;
1381 1373
1382 require Net::SSLeay; 1374 require Net::SSLeay;
1383 1375
1384 Carp::croak "it is an error to call starttls more than once on an Anyevent::Handle object" 1376 Carp::croak "it is an error to call starttls more than once on an AnyEvent::Handle object"
1385 if $self->{tls}; 1377 if $self->{tls};
1386 1378
1387 if ($ssl eq "accept") { 1379 if ($ssl eq "accept") {
1388 $ssl = Net::SSLeay::new ($ctx || TLS_CTX ()); 1380 $ssl = Net::SSLeay::new ($ctx || TLS_CTX ());
1389 Net::SSLeay::set_accept_state ($ssl); 1381 Net::SSLeay::set_accept_state ($ssl);
1478 @linger = (); 1470 @linger = ();
1479 }); 1471 });
1480 } 1472 }
1481} 1473}
1482 1474
1475=item $handle->destroy
1476
1477Shuts 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
1479as possible. You must not call any methods on the object afterwards.
1480
1481Normally, you can just "forget" any references to an AnyEvent::Handle
1482object and it will simply shut down. This works in fatal error and EOF
1483callbacks, as well as code outside. It does I<NOT> work in a read or write
1484callback, so when you want to destroy the AnyEvent::Handle object from
1485within such an callback. You I<MUST> call C<< ->destroy >> explicitly in
1486that case.
1487
1488The handle might still linger in the background and write out remaining
1489data, as specified by the C<linger> option, however.
1490
1491=cut
1492
1493sub destroy {
1494 my ($self) = @_;
1495
1496 $self->DESTROY;
1497 %$self = ();
1498}
1499
1483=item AnyEvent::Handle::TLS_CTX 1500=item AnyEvent::Handle::TLS_CTX
1484 1501
1485This function creates and returns the Net::SSLeay::CTX object used by 1502This function creates and returns the Net::SSLeay::CTX object used by
1486default for TLS mode. 1503default for TLS mode.
1487 1504
1519 1536
1520 1537
1521=head1 NONFREQUENTLY ASKED QUESTIONS 1538=head1 NONFREQUENTLY ASKED QUESTIONS
1522 1539
1523=over 4 1540=over 4
1541
1542=item I C<undef> the AnyEvent::Handle reference inside my callback and
1543still get further invocations!
1544
1545That's because AnyEvent::Handle keeps a reference to itself when handling
1546read or write callbacks.
1547
1548It is only safe to "forget" the reference inside EOF or error callbacks,
1549from within all other callbacks, you need to explicitly call the C<<
1550->destroy >> method.
1551
1552=item I get different callback invocations in TLS mode/Why can't I pause
1553reading?
1554
1555Unlike, say, TCP, TLS connections do not consist of two independent
1556communication channels, one for each direction. Or put differently. The
1557read and write directions are not independent of each other: you cannot
1558write data unless you are also prepared to read, and vice versa.
1559
1560This can mean than, in TLS mode, you might get C<on_error> or C<on_eof>
1561callback invocations when you are not expecting any read data - the reason
1562is that AnyEvent::Handle always reads in TLS mode.
1563
1564During the connection, you have to make sure that you always have a
1565non-empty read-queue, or an C<on_read> watcher. At the end of the
1566connection (or when you no longer want to use it) you can call the
1567C<destroy> method.
1524 1568
1525=item How do I read data until the other side closes the connection? 1569=item How do I read data until the other side closes the connection?
1526 1570
1527If you just want to read your data into a perl scalar, the easiest way 1571If you just want to read your data into a perl scalar, the easiest way
1528to achieve this is by setting an C<on_read> callback that does nothing, 1572to achieve this is by setting an C<on_read> callback that does nothing,
1538 1582
1539The reason to use C<on_error> is that TCP connections, due to latencies 1583The reason to use C<on_error> is that TCP connections, due to latencies
1540and packets loss, might get closed quite violently with an error, when in 1584and packets loss, might get closed quite violently with an error, when in
1541fact, all data has been received. 1585fact, all data has been received.
1542 1586
1543It is usually better to use acknowledgements when transfering data, 1587It is usually better to use acknowledgements when transferring data,
1544to make sure the other side hasn't just died and you got the data 1588to make sure the other side hasn't just died and you got the data
1545intact. This is also one reason why so many internet protocols have an 1589intact. This is also one reason why so many internet protocols have an
1546explicit QUIT command. 1590explicit QUIT command.
1547
1548 1591
1549=item I don't want to destroy the handle too early - how do I wait until 1592=item I don't want to destroy the handle too early - how do I wait until
1550all data has been written? 1593all data has been written?
1551 1594
1552After writing your last bits of data, set the C<on_drain> callback 1595After writing your last bits of data, set the C<on_drain> callback

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines