… | |
… | |
14 | |
14 | |
15 | AnyEvent::Handle - non-blocking I/O on file handles via AnyEvent |
15 | AnyEvent::Handle - non-blocking I/O on file handles via AnyEvent |
16 | |
16 | |
17 | =cut |
17 | =cut |
18 | |
18 | |
19 | our $VERSION = 4.3; |
19 | our $VERSION = 4.32; |
20 | |
20 | |
21 | =head1 SYNOPSIS |
21 | =head1 SYNOPSIS |
22 | |
22 | |
23 | use AnyEvent; |
23 | use AnyEvent; |
24 | use AnyEvent::Handle; |
24 | use AnyEvent::Handle; |
… | |
… | |
59 | treatment of characters applies to this module as well. |
59 | treatment of characters applies to this module as well. |
60 | |
60 | |
61 | All callbacks will be invoked with the handle object as their first |
61 | All callbacks will be invoked with the handle object as their first |
62 | argument. |
62 | argument. |
63 | |
63 | |
64 | =head2 SIGPIPE is not handled by this module |
|
|
65 | |
|
|
66 | SIGPIPE is not handled by this module, so one of the practical |
|
|
67 | requirements of using it is to ignore SIGPIPE (C<$SIG{PIPE} = |
|
|
68 | 'IGNORE'>). At least, this is highly recommend in a networked program: If |
|
|
69 | you use AnyEvent::Handle in a filter program (like sort), exiting on |
|
|
70 | SIGPIPE 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)> |
… | |
… | |
92 | Set the callback to be called when an end-of-file condition is detected, |
84 | Set the callback to be called when an end-of-file condition is detected, |
93 | i.e. in the case of a socket, when the other side has closed the |
85 | i.e. in the case of a socket, when the other side has closed the |
94 | connection cleanly. |
86 | connection cleanly. |
95 | |
87 | |
96 | For sockets, this just means that the other side has stopped sending data, |
88 | For sockets, this just means that the other side has stopped sending data, |
97 | you can still try to write data, and, in fact, one can return from the eof |
89 | you can still try to write data, and, in fact, one can return from the EOF |
98 | callback and continue writing data, as only the read part has been shut |
90 | callback and continue writing data, as only the read part has been shut |
99 | down. |
91 | down. |
100 | |
92 | |
101 | While not mandatory, it is I<highly> recommended to set an eof callback, |
93 | While not mandatory, it is I<highly> recommended to set an EOF callback, |
102 | otherwise you might end up with a closed socket while you are still |
94 | otherwise you might end up with a closed socket while you are still |
103 | waiting for data. |
95 | waiting for data. |
104 | |
96 | |
105 | If an EOF condition has been detected but no C<on_eof> callback has been |
97 | If an EOF condition has been detected but no C<on_eof> callback has been |
106 | set, then a fatal error will be raised with C<$!> set to <0>. |
98 | set, 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 |
… | |
… | |
382 | } |
374 | } |
383 | |
375 | |
384 | =item $handle->autocork ($boolean) |
376 | =item $handle->autocork ($boolean) |
385 | |
377 | |
386 | Enables or disables the current autocork behaviour (see C<autocork> |
378 | Enables or disables the current autocork behaviour (see C<autocork> |
387 | constructor argument). |
379 | constructor argument). Changes will only take effect on the next write. |
388 | |
380 | |
389 | =cut |
381 | =cut |
|
|
382 | |
|
|
383 | sub autocork { |
|
|
384 | $_[0]{autocork} = $_[1]; |
|
|
385 | } |
390 | |
386 | |
391 | =item $handle->no_delay ($boolean) |
387 | =item $handle->no_delay ($boolean) |
392 | |
388 | |
393 | Enables or disables the C<no_delay> setting (see constructor argument of |
389 | Enables or disables the C<no_delay> setting (see constructor argument of |
394 | the same name for details). |
390 | the same name for details). |
… | |
… | |
1379 | sub starttls { |
1375 | sub starttls { |
1380 | my ($self, $ssl, $ctx) = @_; |
1376 | my ($self, $ssl, $ctx) = @_; |
1381 | |
1377 | |
1382 | require Net::SSLeay; |
1378 | require Net::SSLeay; |
1383 | |
1379 | |
1384 | 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" |
1385 | if $self->{tls}; |
1381 | if $self->{tls}; |
1386 | |
1382 | |
1387 | if ($ssl eq "accept") { |
1383 | if ($ssl eq "accept") { |
1388 | $ssl = Net::SSLeay::new ($ctx || TLS_CTX ()); |
1384 | $ssl = Net::SSLeay::new ($ctx || TLS_CTX ()); |
1389 | Net::SSLeay::set_accept_state ($ssl); |
1385 | Net::SSLeay::set_accept_state ($ssl); |
… | |
… | |
1478 | @linger = (); |
1474 | @linger = (); |
1479 | }); |
1475 | }); |
1480 | } |
1476 | } |
1481 | } |
1477 | } |
1482 | |
1478 | |
|
|
1479 | =item $handle->destroy |
|
|
1480 | |
|
|
1481 | Shuts down the handle object as much as possible - this call ensures that |
|
|
1482 | no further callbacks will be invoked and resources will be freed as much |
|
|
1483 | as possible. You must not call any methods on the object afterwards. |
|
|
1484 | |
|
|
1485 | Normally, you can just "forget" any references to an AnyEvent::Handle |
|
|
1486 | object and it will simply shut down. This works in fatal error and EOF |
|
|
1487 | callbacks, as well as code outside. It does I<NOT> work in a read or write |
|
|
1488 | callback, so when you want to destroy the AnyEvent::Handle object from |
|
|
1489 | within such an callback. You I<MUST> call C<< ->destroy >> explicitly in |
|
|
1490 | that case. |
|
|
1491 | |
|
|
1492 | The handle might still linger in the background and write out remaining |
|
|
1493 | data, as specified by the C<linger> option, however. |
|
|
1494 | |
|
|
1495 | =cut |
|
|
1496 | |
|
|
1497 | sub destroy { |
|
|
1498 | my ($self) = @_; |
|
|
1499 | |
|
|
1500 | $self->DESTROY; |
|
|
1501 | %$self = (); |
|
|
1502 | } |
|
|
1503 | |
1483 | =item AnyEvent::Handle::TLS_CTX |
1504 | =item AnyEvent::Handle::TLS_CTX |
1484 | |
1505 | |
1485 | This function creates and returns the Net::SSLeay::CTX object used by |
1506 | This function creates and returns the Net::SSLeay::CTX object used by |
1486 | default for TLS mode. |
1507 | default for TLS mode. |
1487 | |
1508 | |
… | |
… | |
1519 | |
1540 | |
1520 | |
1541 | |
1521 | =head1 NONFREQUENTLY ASKED QUESTIONS |
1542 | =head1 NONFREQUENTLY ASKED QUESTIONS |
1522 | |
1543 | |
1523 | =over 4 |
1544 | =over 4 |
|
|
1545 | |
|
|
1546 | =item I C<undef> the AnyEvent::Handle reference inside my callback and |
|
|
1547 | still get further invocations! |
|
|
1548 | |
|
|
1549 | That's because AnyEvent::Handle keeps a reference to itself when handling |
|
|
1550 | read or write callbacks. |
|
|
1551 | |
|
|
1552 | It is only safe to "forget" the reference inside EOF or error callbacks, |
|
|
1553 | from 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 |
|
|
1557 | reading? |
|
|
1558 | |
|
|
1559 | Unlike, say, TCP, TLS connections do not consist of two independent |
|
|
1560 | communication channels, one for each direction. Or put differently. The |
|
|
1561 | read and write directions are not independent of each other: you cannot |
|
|
1562 | write data unless you are also prepared to read, and vice versa. |
|
|
1563 | |
|
|
1564 | This can mean than, in TLS mode, you might get C<on_error> or C<on_eof> |
|
|
1565 | callback invocations when you are not expecting any read data - the reason |
|
|
1566 | is that AnyEvent::Handle always reads in TLS mode. |
|
|
1567 | |
|
|
1568 | During the connection, you have to make sure that you always have a |
|
|
1569 | non-empty read-queue, or an C<on_read> watcher. At the end of the |
|
|
1570 | connection (or when you no longer want to use it) you can call the |
|
|
1571 | C<destroy> method. |
1524 | |
1572 | |
1525 | =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? |
1526 | |
1574 | |
1527 | If you just want to read your data into a perl scalar, the easiest way |
1575 | If you just want to read your data into a perl scalar, the easiest way |
1528 | to achieve this is by setting an C<on_read> callback that does nothing, |
1576 | to achieve this is by setting an C<on_read> callback that does nothing, |
… | |
… | |
1538 | |
1586 | |
1539 | The reason to use C<on_error> is that TCP connections, due to latencies |
1587 | The reason to use C<on_error> is that TCP connections, due to latencies |
1540 | and packets loss, might get closed quite violently with an error, when in |
1588 | and packets loss, might get closed quite violently with an error, when in |
1541 | fact, all data has been received. |
1589 | fact, all data has been received. |
1542 | |
1590 | |
1543 | It is usually better to use acknowledgements when transfering data, |
1591 | It is usually better to use acknowledgements when transferring data, |
1544 | to make sure the other side hasn't just died and you got the data |
1592 | to make sure the other side hasn't just died and you got the data |
1545 | intact. This is also one reason why so many internet protocols have an |
1593 | intact. This is also one reason why so many internet protocols have an |
1546 | explicit QUIT command. |
1594 | explicit QUIT command. |
1547 | |
|
|
1548 | |
1595 | |
1549 | =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 |
1550 | all data has been written? |
1597 | all data has been written? |
1551 | |
1598 | |
1552 | After writing your last bits of data, set the C<on_drain> callback |
1599 | After writing your last bits of data, set the C<on_drain> callback |