One of the weirdest bits of the API that I’ve run into is that the underlying framework only weakly references Future objects, so if the client doesn’t keep its own reference, then the callbacks will never be invoked. I may not care about “the future object” itself, but I do care about the callbacks I set on it.
I ended up writing a function:
sub hold_future {
my $f = shift;
$f->on_ready(sub { undef $f });
return ();
}
The sub being set does nothing but close over
$f
in order to create a circular reference. That keeps the Future alive until the callbacks are run. To keep the future from persisting forever, though, it destroys that reference once the future resolves.One may safely release the future while the callbacks are running, since the resolution machinery is holding onto a strong reference (
$self
) at that point. Therefore, the future won’t be destroyed until all the callbacks finish.Now, the rest of my code has clearer purpose:
sub md_delete {
my ($cb, $id) = @_;
hold_future(
dynamo_delete($id)
->on_done(sub { $cb->(1) })
->on_fail(sub { $cb->(0); log_event("delete $id: $_[0]") })
);
}
Where
dynamo_delete
invokes a lot of retry/exponential backoff machinery, and md_delete
is a command handler for Memcached::Server.Having worked with jQuery Deferreds, I find it odd that
Future
doesn’t provide a separate Future::Promise
object. It just hopes that the receiver of the future doesn’t try to call creator-related functions like done
.I also find it odd that the future doesn’t just stick around itself, automatically persisting until the callback phase unless actively canceled by the receiver. Having to manually manage them feels surprisingly alien, even though I’m used to managing file handles and lexical scopes.