Do we really need tick()?

[bwoebi]

What exactly is the purpose of tick() except leaking the internal detail of being "ticked"?

A tick is easily simulated with (using Amp's interface):

$reactor->immediately(function() use ($reactor) {
    $reactor->immediately(function() use ($reactor) {
        $reactor->stop();
    });
});
$reactor->run();

It's a nice helper function, but does it really have to be directly accessible? Also, the only usage for tick()'s I've seen so far is to wait for a single promise, which can be also written as:

$promise->when(function() use ($reactor) {
    $reactor->stop();
});
$reactor->run();

[WyriHaximus]

Honestly the only time I had to use tick() was when I had to force the loop to iterate to achieve compatibility with Guzzle. It's a bad thing to do from within a running loop but couldn't find another way at the time.

[bwoebi]

You mean like … you tried to tick() two loops at a same time?

That sounds horrible … (and even then you just could poll the guzzle event loop each 50 ms for example)

[trowski]

I've used it to provide compatibility with synchronous APIs. Your example stops the loop after the promise is resolved, but perhaps you just wanted to tick the loop manually, stopping control flow until the promise is resolved, but otherwise allowing the loop to continue running.

It's inelegant and horrible in an actual async program, but sometimes you want to mix sync and async. That's the only time I see tick() being useful. If there's a better way to do it, I'm listening because fundamentally I agree, tick() really shouldn't be exposed.

[WyriHaximus]

No I forced the currently running loop to iterate over and over again until the request guzzle is waiting for is done. I'll have a look at it again to see if there is a better way now or that I've missed but yes it is a miserable but effective way of doing it.

[bwoebi]

@trowski You mean like stopping everything else until a specific task is completed? … Could you please rephrase what you mean?

[trowski]

@bwoebi Here's an example:

function wait(Promise $promise, EventLoop $loop)
    while ($promise->isPending()) {
        // Ticks the event loop, dispatching events, but this control flow context waits here.
        $loop->tick();
    }

    return $promise->getResult();
}

The event loop can be running before and after wait() is run, but it allows a promise to be synchronously waited on within a running event loop. It's far from ideal, but it works. Not something I'd recommend in a truly async program.

[WyriHaximus]

@trowski used the exact same thing in my guzzle handler 👍 . Not something I enjoyed doing but it was effective. One of the problems is that your callstack keeps increasing and memory keeps building until the entire stack is resolved.

[bwoebi]

Oh, you want to invoke tick() while running … That's something which Amp outright forbids https://github.com/amphp/amp/blob/master/lib/NativeReactor.php#L147-L151

Hmm

I'm not sure why you'd want to do that though … Also, uhm … isn't that working for exactly one single Promise, if you have two wait()'s, you'll only be able to resolve the first one after the second one has resolved… that sounds really awkward and I'm not sure if we should support that…

But I don't get why you can just call $reactor->run() and $reactor->stop() there in an immediate (assuming that we'll allow nesting run() calls (?))

[kelunik]

I think we should implement the wait mechanism just as

function wait(Promise $promise) {
    run(coroutine(function() (&$value) {
        $value = yield $promise;
        stop();
    });

    return $value;
}

[bwoebi]

Precisely this ;-)

Which actually is the same than

$promise->when(function() use ($reactor) {
    $reactor->stop();
});
$reactor->run();

from the initial post, just formulated in another way.

[kelunik]

wait should only be used in tests / legacy apps that mix both (async & sync) frequently, I think the small overhead of emulating it is fine there for the sake of not leaking tick.

[trowski]

@kelunik I agree, outside of integrating async with sync code, tests are only other place I've ever used wait() or tick(). Let's not have tick() as part of the interface and emulate wait() as @bwoebi suggested. Best of both worlds.