view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    A further complication of cancellation comes from the case where a
    given future is reused multiple times for multiple sequences or
    convergent trees.

    In particular, it is in clear in each of the following examples what
    the behaviour of $f2 should be, were $f1 to be cancelled:

       my $f_initial = Future->new; ...
       my $f1 = $f_initial->then( ... );
       my $f2 = $f_initial->then( ... );
    
       my $f1 = Future->needs_all( $f_initial );
       my $f2 = Future->needs_all( $f_initial );

    The point of cancellation propagation is to trace backwards through
    stages of some larger sequence of operations that now no longer need to
    happen, because the final result is no longer required. But in each of
    these cases, just because $f1 has been cancelled, the initial future
    $f_initial is still required because there is another future ($f2) that
    will still require its result.

    Initially it would appear that some kind of reference-counting
    mechanism could solve this question, though that itself is further
    complicated by the on_ready handler and its variants.

    It may simply be that a comprehensive useful set of cancellation
    semantics can't be universally provided to cover all cases; and that
    some use-cases at least would require the application logic to give
    extra information to its Future objects on how they should wire up the
    cancel propagation logic.

    Both of these cancellation issues are still under active design
    consideration; see the discussion on RT96685 for more information
    (https://rt.cpan.org/Ticket/Display.html?id=96685).

SEE ALSO

      * Future::AsyncAwait - deferred subroutine syntax for futures

      Provides a neat syntax extension for writing future-based code.

      * Future::IO - Future-returning IO methods

      Provides methods similar to core IO functions, which yield results by
      Futures.

      * Promises - an implementation of the "Promise/A+" pattern for
      asynchronous programming

      A different alternative implementation of a similar idea.

      * curry - Create automatic curried method call closures for any class
      or object

      * "The Past, The Present and The Future" - slides from a talk given
      at the London Perl Workshop, 2012.

      https://docs.google.com/presentation/d/1UkV5oLcTOOXBXPh8foyxko4PR28_zU_aVx6gBms7uoo/edit

      * "Futures advent calendar 2013"

      http://leonerds-code.blogspot.co.uk/2013/12/futures-advent-day-1.html

      * "Asynchronous Programming with Futures" - YAPC::EU 2014

      https://www.youtube.com/watch?v=u9dZgFM6FtE

TODO

      * Consider the ability to pass the constructor a block CODEref,
      instead of needing to use a subclass. This might simplify async/etc..
      implementations, and allows the reuse of the idea of subclassing to
      extend the abilities of Future itself - for example to allow a kind
      of Future that can report incremental progress.

AUTHOR

    Paul Evans <leonerd@leonerd.org.uk>