If tick is called, wait for next like the run() loop does

[JurJean]

I don't know why these two methods do something different. Is there a reason for it? Anyway, this PR allows me to wait for some stuff while keeping the loop running.

If you guys approve, I'll be happy to clean the code up a bit.

[JurJean]

Would be awesome to get a response on this!

[clue]

Thanks for filing this PR 👍

This change is contrary to what has been done in reactphp/reactphp#204 a while back.

I think the non-blocking tick() makes more sense, what do you think about this? What is the motivation for this change?

[JurJean]

The motivation is a recent pull request at clue/reactphp-block#19, where you asked me the same question :)

Personally I expect tick() to be a single action of what run() does all the time. Thus blocking for a bit, running the next action it needs to run. Why would one tick when nothing happens, and how is one supposed to use tick() if you can't do it in a loop (aside from unittesting)?

I've took a look at libevent and the tick() behaves the same as the stream loop currently. Now that I think of it, why not something like a wait() or tickAndWait() method? Should be possible with all event loop adapters.

[clue]

I've took a look at libevent and the tick() behaves the same as the stream loop currently.

Thanks for confirming back that the current behavior is consistent in never blocking and that this PR would introduce a breaking change here.

Personally I expect tick() to be a single action of what run() does all the time. Thus blocking for a bit, running the next action it needs to run. Why would one tick when nothing happens, and how is one supposed to use tick() if you can't do it in a loop (aside from unittesting)?

I think you're raising a very valid question here: What is a "tick"? :-)

This is certainly underdocumented, so I understand where you're coming from. Personally, I would consider a "tick" to always be "instant" and as such never be blocking.

That being said, I'm undecided if having the tick() method is actually a good idea. In practice, there's very little use for it and I've only ever really seen it used in test setups (often with some rather fragile assumptions).

Also, should it really ever be necessary, it can also be be emulated quite easily like this:

$loop->futureTick(function () use ($loop) {
$loop->stop();
});
$loop->run();

I'm leaning towards suggesting we should drop this entirely (BC break ahead, obviously).

See also async-interop/event-loop#9