Watcher methods called on stopped loop
trowski opened this issue · 7 comments
Should calling a watcher method on a stopped loop throw an exception?
I'm not sure what behavior makes sense in this situation. It may make sense to create an initial set of watchers, then start the loop. I can also see where it could be a mistake to create a watcher in a loop that is not running, so throwing would be preferred.
My initial thoughts are to allow creating a watcher in a stopped loop under the assumption that it will be started. With the current interface this would have to be the case, as Loop::execute() executes the callback provided, then calls LoopDriver::run().
For watcher methods to throw exceptions from a stopped loop, LoopDriver::run() would have to accept a callback, start the loop, then execute the callback.
I think throwing is not really possible as we want to support Loop calls from synchronous code.
As you probably were inspired by the discussion on whenable: It's rather something whenable has to solve to not defer() to a stopped loop.
In general, we cannot make assumptions about whether the loop will be run (again) or not. So not much we can do here, IMO.
We don't have a stopped loop, it's no loop then. But once we have the factory, we could create the driver upon the first watcher creation already, but still unset it after it has been run.
Libraries wishing to implement wait have to have a factory that always returns the same loop instance, so it can be run again.
I can totally see the need for it, if we want to support synchronous wait, but I don't see a good way to implement it currently. Because every execute might have a $driver passed, that's completely different from the one which has been used to setup the things.
We could (of course), queue them in Loop and wait for Loop::execute.
Yes, it does, thanks!