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.108 by root, Tue Jan 6 20:08:05 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");
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
382} 374}
383 375
384=item $handle->autocork ($boolean) 376=item $handle->autocork ($boolean)
385 377
386Enables or disables the current autocork behaviour (see C<autocork> 378Enables or disables the current autocork behaviour (see C<autocork>
387constructor argument). 379constructor argument). Changes will only take effect on the next write.
388 380
389=cut 381=cut
382
383sub autocork {
384 $_[0]{autocork} = $_[1];
385}
390 386
391=item $handle->no_delay ($boolean) 387=item $handle->no_delay ($boolean)
392 388
393Enables or disables the C<no_delay> setting (see constructor argument of 389Enables or disables the C<no_delay> setting (see constructor argument of
394the same name for details). 390the same name for details).
1379sub starttls { 1375sub 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
1481Shuts down the handle object as much as possible - this call ensures that
1482no further callbacks will be invoked and resources will be freed as much
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.
1491
1492The handle might still linger in the background and write out remaining
1493data, as specified by the C<linger> option, however.
1494
1495=cut
1496
1497sub 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
1485This function creates and returns the Net::SSLeay::CTX object used by 1506This function creates and returns the Net::SSLeay::CTX object used by
1486default for TLS mode. 1507default 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
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.
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
1527If 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
1528to 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,
1538 1586
1539The 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
1540and 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
1541fact, all data has been received. 1589fact, all data has been received.
1542 1590
1543It is usually better to use acknowledgements when transfering data, 1591It is usually better to use acknowledgements when transferring data,
1544to 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
1545intact. 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
1546explicit QUIT command. 1594explicit 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
1550all data has been written? 1597all data has been written?
1551 1598
1552After 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

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines