Bug #124008 for future: Design thoughts on "sleep" API

Thu Jan 04 11:26:45 2018 leonerd-cpan [...] leonerd.org.uk - Ticket created

Subject:

Design thoughts on "sleep" API

Currently, the abstract Future API does not know how to "sleep"; i.e. to wait for some fixed duration of time, or until some fixed future moment, before continuing. This inability makes it impossible to implement a variety of utility functions that would otherwise be useful, chief among them being any sort of "retry with delays until success" wrapper function. For example, such a function is implemented at https://github.com/matrix-org/sytest/blob/develop/run-tests.pl#L347 but is specific to IO::Async, because its implementation calls the delay() function which itself has to capture the $loop lexical to provide the ->delay_future method. If there was a generic sleep-like ability provided in some standard location, then this wrapper could be made more generic and live in the Future distribution itself. -- Paul Evans

Thu Jan 04 11:41:46 2018 leonerd-cpan [...] leonerd.org.uk - Correspondence added

A possible solution to this may be to take a small step down the slippery slope of "design an event system API" because that's everyone's fun game. A well-known package variable could point to some instance (or package) that provides methods confirming to some minimal API. E.g. $f = $Future::IMPL->delay( after => $secs ) $f = $Future::IMPL->delay( until => $epoch ) This then raises an interesting question of how that value gets set. Primarily that would be set by whatever is "providing" base-level leaf futures. For example, IO::Async::Loop, POEx::Future, etc... can set that to point to some instance or package which provides appropriate methods. At which point, it feels tempting to add an 'await' method in that interface too, thus solving the subclassing problem otherwise raised by RT#123778, by perhaps: $Future::IMPL->await( $f ) By doing this we have to be a little more careful in "jenga" situations however. Under a jenga tree, it would be quite sufficient for any of the event looplets to provide the 'delay' API, because the tree provides the guarantee that any of them has a sleep ability. It's not necessarily given that any arbitrarily chosen looplet will be able to implement the await ability however. In general the await ability would need to be provided by the root looplet in the jenga tree. Exactly how they determine which one that is remains an open design question - it isn't necessarily the first, nor the final, loaded module. See also https://rt.cpan.org/Ticket/Display.html?id=123778 -- Paul Evans

Wed Apr 10 08:56:10 2019 leonerd-cpan [...] leonerd.org.uk - Correspondence added

On Thu Jan 04 11:41:46 2018, PEVANS wrote: Show quoted text

> A possible solution to this may be to take a small step down the > slippery slope of "design an event system API" because that's > everyone's fun game. A well-known package variable could point to some > instance (or package) that provides methods confirming to some minimal > API. > > E.g. > > $f = $Future::IMPL->delay( after => $secs ) > $f = $Future::IMPL->delay( until => $epoch ) > > This then raises an interesting question of how that value gets set. > Primarily that would be set by whatever is "providing" base-level leaf > futures. For example, IO::Async::Loop, POEx::Future, etc... can set > that to point to some instance or package which provides appropriate > methods.

This part is now being done by the new Future::IO module. Show quoted text

> At which point, it feels tempting to add an 'await' method in that > interface too, thus solving the subclassing problem otherwise raised > by RT#123778, by perhaps: > > $Future::IMPL->await( $f ) > > By doing this we have to be a little more careful in "jenga" > situations however. Under a jenga tree, it would be quite sufficient > for any of the event looplets to provide the 'delay' API, because the > tree provides the guarantee that any of them has a sleep ability. It's > not necessarily given that any arbitrarily chosen looplet will be able > to implement the await ability however. In general the await ability > would need to be provided by the root looplet in the jenga tree. > Exactly how they determine which one that is remains an open design > question - it isn't necessarily the first, nor the final, loaded > module. > > > See also > https://rt.cpan.org/Ticket/Display.html?id=123778

This remains an unanswered question, but has its own issue. I can close this one now. -- Paul Evans

Wed Apr 10 08:56:15 2019 leonerd-cpan [...] leonerd.org.uk - Status changed from 'new' to 'resolved'