Browse files

revert 3f31648 since it makes timer go away in the long poll.

Added a unit test thanks to yoshimax
  • Loading branch information...
1 parent d0361d6 commit 0b1e10c4808cc33a0c540d724a6f6272e66d9777 @miyagawa committed Jan 31, 2010
Showing with 17 additions and 2 deletions.
  1. +0 −2 lib/Tatsumaki/
  2. +17 −0 t/mq/timer.t
@@ -73,7 +73,6 @@ sub flush_events {
undef $client;
delete $self->clients->{$client_id};
- Scalar::Util::weaken $client->{timer};
} catch {
/Tatsumaki::Error::ClientDisconnect/ and do {
@@ -103,7 +102,6 @@ sub poll_once {
warn "Timing out $client_id long-poll" if DEBUG;
- Scalar::Util::weaken $client->{timer};
if ($is_new) {
# flush backlog for a new client
@@ -0,0 +1,17 @@
+use Test::More;
+use Tatsumaki::MessageQueue;
+my $channel = 'test1';
+my $client_id = rand(1);
+my $cv = AE::cv;
+my $t = AE::timer 3, 0, sub { $cv->croak( "timeout" ); };
+my $sub = Tatsumaki::MessageQueue->instance( $channel );
+$sub->poll_once($client_id, sub { ok(1, 'long poll timeout'),
+ $cv->send }, 1);

5 comments on commit 0b1e10c


It looks good since it seems that AE::timer doesn't cause cyclic reference (at least with AnyEvent 5.24).

You also need not to weaken $self though the code is just fine.


Sorry I was completely wrong. memory_cycle_ok( $t ) is also failed if you use AnyEvent::Impl::Perl.

( Hmm, it may be because memory_cycle_ok doesn't work for XS structure.)

Then I checked by following script. It seems that there is no leaks.


WTF, there may be leaks when I use AnyEvent::Impl::Perl.

Should I fix it?


Doesn't seem to leak on EV, EventLib, Event, Glib, Tk, Qt and IOAsync.
But slightly leaks on Perl and hell a LOT on POE. Maybe it's an Impl bug of those AE backends.


Eventually, I got the result which reveals that there is no leak even if I use AE::Impl::Perl or POE.

Thanks for your advice and I'm sorry for all the fuss.

Please sign in to comment.