Skip Menu |

This queue is for tickets about the POE-Component-Generic CPAN distribution.

Report information
The Basics
Id: 32067
Status: resolved
Worked: 1 hour (60 min)
Priority: 0/
Queue: POE-Component-Generic

People
Owner: Nobody in particular
Requestors: FRODWITH [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.1008
Fixed in: (no value)



Subject: Postback IDs
POE-Component-Generic-0.1008 perl -v: This is perl, v5.8.8 built for darwin-2level uname -a: Darwin hephaestus.local 8.11.1 Darwin Kernel Version 8.11.1: Wed Oct 10 18:23:28 PDT 2007; root:xnu-792.25.20~1/RELEASE_I386 i386 i386 Calling postbacks and saving the values in the child breaks if where you save it depends on some other arguments: only the last value will be saved, because the PBids will be the same. (note: the following code is imaginary, and wouldn't work at all as written. we'd have to convert coderefs to states, etc...) <code> #...parent... child->set_a_postback_for_later({}, 'Quiznos', sub { return "Toasty."; }); child->set_a_postback_for_later({}, 'Subway', sub { return "Not-toasty."; }); #...child... sub set_a_postback_for_later { my ($self, $name, $pb) = @_; shift->{callbacks}->{$name} = $pb; } #...much later... $self->{callbacks}->{'Quiznos'}->(); Show quoted text
>>> "Not-toasty" # clearly untrue!
</code> This happens because PBIDs are based solely on the postback-signature. This can be fixed by making PBIDs more unique: 1) have them include the rest of their arguments 2) use some other unique identifier 1 would make the PBIDs arbitrarily long and I don't like it, 2 is used in the attached patch (just an incrementing integer). The patch has the outside possibility of overflowing if Perl's arbitrary precision arithmetic isn't baked in, but then you'd just get a wrap (and unless you're trying to store 4 billion different postbacks, that won't be a problem. Also, wraps are really tasty). If that's a concern, Data::UUID would give us something guaranteed unique, but that's adding a dependancy. I'd be happy to cook up a patch for that if you think it's better. Thanks for looking at this. :) -Paul p.s. It's almost lunchtime and I missed breakfast, sorry for the food metaphors...
Subject: possible_fix.patch
52a53,54 > > $self->{next_PBid} = 0; 462c464,468 < --- > sub __next_PBid > { > my $num = shift->{next_PBid}++; > return "---POSTBACK-$num---"; > } 477c483 < my $PBid = "---POSTBACK-$params->{package}-$pmap->{method}-$pos---"; --- > my $PBid = $self->__next_PBid(); 1487c1493 < \ No newline at end of file --- >
From: perl [...] pied.nu
I believe the thought I had in my mind as I wrote that code is that a method that accepts a postback would release and replace the PB with the new one when next it is called. Which is why you get "Not-toasty". If each method call with a PB generates a new PBID, a mechanism is need to find out when the subref is released in the child. Which means PoCo::Generic has to tie the subref in the child, which might break some code. The question becomes, which behaviour is "least suprising" : a - A subref becomes a tied subref; b - a postback erases the previous postback. a - wins, I think, because it will suprise fewer people. Regarding a tied subref, maybe jumping through some clever hoops would allow us to hook the DESTROY call of a postback what was tied by application code (as opposed to tied by PoCo::Generic).
Fixed in 0.1100, which is making its way to the CPAN. I found an even simpler solution; do away with PBIDs completely. The child is given the session/event to post to. It sends this tupple back when the postback is called. No postback tracking in the parent. No potential leaks. WIN!