Day 23 - Additional Benefits of Futures
Beyond simply being able replicate regular perl control-flow styles, building program logic on top of Futures has many additional benefits.
The primary benefit is of course the ability to work asynchronously, allowing the concurrency of being able to start multiple operations and wait for them all to succeed. We have seen this with the tree-forming needs_all, needs_any and wait_any constructor methods, and the fmap utility.
my $f = Future->needs_all( ONE(), TWO(), THREE(), ); my ( $one, $two, $three ) = $f->get;
my $f = fmap1 {
FUNC($_),
} foreach => [ @VALUES ], concurrent => 10;
my @results = $f->get;
Because Futures represent an operation in progress they are an ideal place to provide cancellation logic, allowing the consumer of the would-be result to abandon it and declare it no longer useful. This can be done explicitly by calling the cancel method.
sub PROCESS_REQUEST {
my ( $req ) = @_;
my $f = GET_RESULT( $req->PARAMS );
$f->on_done(sub {
$req->REPLY( @_ );
});
$req->ON_CLIENT_CLOSE(sub {
$f->cancel;
});
return $f;
}
A failed Future provides an analog to a thrown exception, causing an entire chain or tree of operations to be abandoned and propagating back up towards the caller until a suitable error-handling block is found. In addition however, a failed Future can provide a full list of values as well as a single string. This allows error handlers to be much more fine-grained in their ability to distinguish different types of error.
my $f = GET("http://my-site-here.com/")
->else_with_f(sub {
my ( $f, $failure, $op ) = @_;
# may be http, $request, $response
if( $op eq "http" and $_[3]->code == 500 ) {
say "Server is unavailable";
return Future->new->done( $HOLDING_PAGE );
}
return $f;
});
Middleware library functions can easily be built on top of basic actions implemented by futures and providing more of their own. When writing and testing sub libraries it becomes a simple matter to use these futures within the unit-tests themselves as a way to mock out responses from lower levels of logic in order to test the library code in isolation. For example, if we wish to unit-test a middleware function that uses an HTTP user agent to fetch a page, parse it, and return the page title we can provide a simple tiny user agent wrapper that just returns a new future, and does nothing else:
my $resp_f; my $url;
sub GET {
( $url ) = @_;
return $resp_f = Future->new;
}
...
Our unit test can then drive the behaviour of that "user agent", as well as testing the function's results:
... my $f = get_page_title( \&GET, "http://my-site-here.com/" ); isa_ok( $f, "Future" ); is( $url, "http://my-site-here.com/" ); ok( defined $resp_f, 'Response future created' ); is( !$f->is_ready, '$f is not yet ready' ); $resp_f->done( HTTP::Response->new( 200, "OK", [ Content_type => "text/html" ], "<html><head><title>My title</title></head><body /></html>", )); ok( $f->is_ready, '$f is now ready after HTML response' ); is( scalar $f->get, "My title", '$f->get returns title' );
Because we have a future to represent both sides of the function (its caller and the inner GET function it uses to fetch the page content) we have been able to easily test the function in the middle. The unit test script itself at various times takes on the role either of the outside caller or the inner HTTP user agent, and is able to easily interleave the two to ensure a neat test.
Edit 2013/12/29: Updated to use else_with_f
Nice post thanks for sharring
ReplyDelete