… | |
… | |
23 | use AnyEvent; |
23 | use AnyEvent; |
24 | use AnyEvent::Handle; |
24 | use AnyEvent::Handle; |
25 | |
25 | |
26 | my $cv = AnyEvent->condvar; |
26 | my $cv = AnyEvent->condvar; |
27 | |
27 | |
28 | my $handle = |
28 | my $hdl; $hdl = new AnyEvent::Handle |
29 | AnyEvent::Handle->new ( |
|
|
30 | fh => \*STDIN, |
29 | fh => \*STDIN, |
31 | on_eof => sub { |
30 | on_error => sub { |
|
|
31 | warn "got error $_[2]\n"; |
32 | $cv->send; |
32 | $cv->send; |
33 | }, |
|
|
34 | ); |
33 | ); |
35 | |
34 | |
36 | # send some request line |
35 | # send some request line |
37 | $handle->push_write ("getinfo\015\012"); |
36 | $hdl->push_write ("getinfo\015\012"); |
38 | |
37 | |
39 | # read the response line |
38 | # read the response line |
40 | $handle->push_read (line => sub { |
39 | $hdl->push_read (line => sub { |
41 | my ($handle, $line) = @_; |
40 | my ($hdl, $line) = @_; |
42 | warn "read line <$line>\n"; |
41 | warn "got line <$line>\n"; |
43 | $cv->send; |
42 | $cv->send; |
44 | }); |
43 | }); |
45 | |
44 | |
46 | $cv->recv; |
45 | $cv->recv; |
47 | |
46 | |
… | |
… | |
102 | This is the error callback, which is called when, well, some error |
101 | This is the error callback, which is called when, well, some error |
103 | occured, such as not being able to resolve the hostname, failure to |
102 | occured, such as not being able to resolve the hostname, failure to |
104 | connect or a read error. |
103 | connect or a read error. |
105 | |
104 | |
106 | Some errors are fatal (which is indicated by C<$fatal> being true). On |
105 | Some errors are fatal (which is indicated by C<$fatal> being true). On |
107 | fatal errors the handle object will be shut down and will not be usable |
106 | fatal errors the handle object will be destroyed (by a call to C<< -> |
108 | (but you are free to look at the current C<< ->rbuf >>). Examples of fatal |
107 | destroy >>) after invoking the error callback (which means you are free to |
109 | errors are an EOF condition with active (but unsatisifable) read watchers |
108 | examine the handle object). Examples of fatal errors are an EOF condition |
110 | (C<EPIPE>) or I/O errors. |
109 | with active (but unsatisifable) read watchers (C<EPIPE>) or I/O errors. |
111 | |
110 | |
112 | AnyEvent::Handle tries to find an appropriate error code for you to check |
111 | AnyEvent::Handle tries to find an appropriate error code for you to check |
113 | against, but in some cases (TLS errors), this does not work well. It is |
112 | against, but in some cases (TLS errors), this does not work well. It is |
114 | recommended to always output the C<$message> argument in human-readable |
113 | recommended to always output the C<$message> argument in human-readable |
115 | error messages (it's usually the same as C<"$!">). |
114 | error messages (it's usually the same as C<"$!">). |
… | |
… | |
369 | if $self->{on_read}; |
368 | if $self->{on_read}; |
370 | |
369 | |
371 | $self->{fh} && $self |
370 | $self->{fh} && $self |
372 | } |
371 | } |
373 | |
372 | |
374 | sub _shutdown { |
373 | #sub _shutdown { |
375 | my ($self) = @_; |
374 | # my ($self) = @_; |
376 | |
375 | # |
377 | delete @$self{qw(_tw _rw _ww fh wbuf on_read _queue)}; |
376 | # delete @$self{qw(_tw _rw _ww fh wbuf on_read _queue)}; |
378 | $self->{_eof} = 1; # tell starttls et. al to stop trying |
377 | # $self->{_eof} = 1; # tell starttls et. al to stop trying |
379 | |
378 | # |
380 | &_freetls; |
379 | # &_freetls; |
381 | } |
380 | #} |
382 | |
381 | |
383 | sub _error { |
382 | sub _error { |
384 | my ($self, $errno, $fatal, $message) = @_; |
383 | my ($self, $errno, $fatal, $message) = @_; |
385 | |
384 | |
386 | $self->_shutdown |
|
|
387 | if $fatal; |
|
|
388 | |
|
|
389 | $! = $errno; |
385 | $! = $errno; |
390 | $message ||= "$!"; |
386 | $message ||= "$!"; |
391 | |
387 | |
392 | if ($self->{on_error}) { |
388 | if ($self->{on_error}) { |
393 | $self->{on_error}($self, $fatal, $message); |
389 | $self->{on_error}($self, $fatal, $message); |
|
|
390 | $self->destroy; |
394 | } elsif ($self->{fh}) { |
391 | } elsif ($self->{fh}) { |
|
|
392 | $self->destroy; |
395 | Carp::croak "AnyEvent::Handle uncaught error: $message"; |
393 | Carp::croak "AnyEvent::Handle uncaught error: $message"; |
396 | } |
394 | } |
397 | } |
395 | } |
398 | |
396 | |
399 | =item $fh = $handle->fh |
397 | =item $fh = $handle->fh |
… | |
… | |
1671 | callbacks, as well as code outside. It does I<NOT> work in a read or write |
1669 | callbacks, as well as code outside. It does I<NOT> work in a read or write |
1672 | callback, so when you want to destroy the AnyEvent::Handle object from |
1670 | callback, so when you want to destroy the AnyEvent::Handle object from |
1673 | within such an callback. You I<MUST> call C<< ->destroy >> explicitly in |
1671 | within such an callback. You I<MUST> call C<< ->destroy >> explicitly in |
1674 | that case. |
1672 | that case. |
1675 | |
1673 | |
|
|
1674 | Destroying the handle object in this way has the advantage that callbacks |
|
|
1675 | will be removed as well, so if those are the only reference holders (as |
|
|
1676 | is common), then one doesn't need to do anything special to break any |
|
|
1677 | reference cycles. |
|
|
1678 | |
1676 | The handle might still linger in the background and write out remaining |
1679 | The handle might still linger in the background and write out remaining |
1677 | data, as specified by the C<linger> option, however. |
1680 | data, as specified by the C<linger> option, however. |
1678 | |
1681 | |
1679 | =cut |
1682 | =cut |
1680 | |
1683 | |
… | |
… | |
1747 | |
1750 | |
1748 | $handle->on_read (sub { }); |
1751 | $handle->on_read (sub { }); |
1749 | $handle->on_eof (undef); |
1752 | $handle->on_eof (undef); |
1750 | $handle->on_error (sub { |
1753 | $handle->on_error (sub { |
1751 | my $data = delete $_[0]{rbuf}; |
1754 | my $data = delete $_[0]{rbuf}; |
1752 | undef $handle; |
|
|
1753 | }); |
1755 | }); |
1754 | |
1756 | |
1755 | The reason to use C<on_error> is that TCP connections, due to latencies |
1757 | The reason to use C<on_error> is that TCP connections, due to latencies |
1756 | and packets loss, might get closed quite violently with an error, when in |
1758 | and packets loss, might get closed quite violently with an error, when in |
1757 | fact, all data has been received. |
1759 | fact, all data has been received. |