Skip Menu |
 

This queue is for tickets about the future CPAN distribution.

Report information
The Basics
Id: 124008
Status: resolved
Priority: 0/
Queue: future

People
Owner: Nobody in particular
Requestors: leonerd-cpan [...] leonerd.org.uk
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: Design thoughts on "sleep" API
Download (untitled) / with headers
text/plain 835b
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
Download (untitled) / with headers
text/plain 1.5k
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
Download (untitled) / with headers
text/plain 1.7k
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.