Nice!
Stephen R. van den Berg wrote:
>Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>>My variant with Concurrent.all does work as intended though, and does
>>not require a Promise in.
>I'll do some more tests to see what happens when, and will see if I can
>devise a
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>Does that work for you? My initial attempts were along those lines,
>but failed to actually wait before returning the result. And when I
>try your version, I get the result immediately when I ->success() the
>original
Does that work for you? My initial attempts were along those lines,
but failed to actually wait before returning the result. And when I
try your version, I get the result immediately when I ->success() the
original promise...
My variant with Concurrent.all does work as intended though, and does
//! Return a @[Future] that will be fulfilled with the fulfilled
//! result of this @[Future], but not until at least @[seconds] have passed.
this_program delay(int|float seconds)
{
Promise p = promise_factory();
on_failure(p->try_failure);
return depend( ({
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>Sorry, that should have been ->map(`[], 0) instead of ->transform(`[], 0,
>0), otherwise failures are not propagated correctly...
Thanks for the heads up. Already figured that out earlier.
I now have something like
Sorry, that should have been ->map(`[], 0) instead of ->transform(`[], 0,
0), otherwise failures are not propagated correctly...
After a bit of testing, I found this solution using only existing
stuff:
Concurrent.Future delay(Concurrent.Future f, int|float t)
{
return Concurrent.all(f, Concurrent.Promise()->timeout(t)->then(`+, `+))
->transform(`[], 0, 0);
}
Could easily be made into a method of Future (using
Stephen R. van den Berg wrote:
>Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>>able to do it by calling ->depend() with another Future that completes
>>after N seconds, right?
>Correct.
>Which does mean that I still have to construct that generic "delay-promise".
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>able to do it by calling ->depend() with another Future that completes
>after N seconds, right?
Correct.
Which does mean that I still have to construct that generic "delay-promise".
I'd like to give it a home
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>I don't follow at all. Setting the delay before the real result has
>arrived doesn't mean anything.
It depends on the semantics of the delay() function. Apparently what you
have in mind and what I had were different
Anyway, if, for whatever reason, you just want to withhold success
for the first N seconds from creation of your Promise, you should be
able to do it by calling ->depend() with another Future that completes
after N seconds, right?
I don't follow at all. Setting the delay before the real result has
arrived doesn't mean anything. After 20 seconds there is nothing you
can do if the result is not available, so setting a 20 second delay
without setting a value is completely pointless. What you should do
is call delay(5,
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>Hm, ok. But I guess you could reuse the callout-reference used for
>timeout then? Because there is no point in having both a delayed
>success and a delayed failure at the same time (whichever would happen
>further
Hm, ok. But I guess you could reuse the callout-reference used for
timeout then? Because there is no point in having both a delayed
success and a delayed failure at the same time (whichever would happen
further ahead in time is a no-op).
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
>(Also, it should use try_success(), not success().)
Details aside, a proper implementation also should cancel the callback
when the promise fails (so the extra state here is the callout-reference).
--
Stephen.
(Also, it should use try_success(), not success().)
(Ok, a real implementation should of course check if set_backend() has
been called in the Promise as well, but that doesn't change the
principle of it.)
I'm sorry, isn't this just
void future_success(Promise p, float|int delay, mixed value)
{
call_out(p->success, delay, value);
}
? Why would a new class or new state information be needed?
Stephen R. van den Berg wrote:
>The first thing that comes to mind would be to create a new member function
>of Concurrent.Future, i.e. next to the timeout() already there, we could
>introduce a delay() which would then semantically be something like:
On second thought, that would increase the
20 matches
Mail list logo
