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 (which is not to say that either one is better).
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.
In my case, I set a delay *always* without a value, I just tell the promise to pretend it has not been fulfilled for the first x seconds. So, if, after 20 seconds, the result is not available yet, I simply do nothing and wait for the real result to come in, which I then pass along promptly.
What you should do is call delay(5, value) when the value is available. Then the timeout can be removed becase 15 > 5. If the value arrives after 35 seconds, calling delay(-15, value) will throw because the promise has already been fulfilled (broken?) by the timeout. (You could provide a
This sounds complicated because it forces me to note times and do my own arithmetic to figure out how much time has passed.
I'd prefer it if (just like timeout()) the seconds passed to the delay function start counting from now (i.e. the moment I create the promise).
So, if I run like:
db->promise_query("SELECT * FROM largetable") .delay(20).timeout(30) .on_success(Yay) .on_failure(Boo);
Then: - If the SQL query takes 5 seconds, I expect Yay() to be called at t=20s - If the SQL query takes 10 seconds, I expect Yay() to be called at t=20s - If the SQL query takes 15 seconds, I expect Yay() to be called at t=20s - If the SQL query takes 25 seconds, I expect Yay() to be called at t=25s - If the SQL query takes 35 seconds, I expect Boo() to be called at t=30s
This only has a single timeframe reference, and is easy to follow (for me at least). Comments?