On 02/27/2014 08:57 PM, Ben Darnell wrote:
Tornado doesn't have any support for the functionality you're
describing. It looks like urwid is monkey patching tornado:
https://github.com/wardi/urwid/blob/master/urwid/main_loop.py#L915
Personally I'm -1 on this feature; "idleness" is ill-defined and will
either run the function too often or too rarely. It's better to either
trigger it based on some appropriate event or just put it on a timer.
Agreed. I think the first time I saw this concept was on libev [0], and
we also inherited it on libuv, but they run always on each loop
iteration. There is an extra "feature" idle handles have, when they are
active the loop will do a 0 timeout poll for i/o, preventing it from
blocking.
IMHO asyncio is a higher level framework which shouldn't have this and
things can be done another way as Ben pointed out. Otherwise next
someone will ask is prepare and check handles are ok too ;-)
[0]:
http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#code_ev_idle_code_when_you_ve_got_no
-Ben
On Thu, Feb 27, 2014 at 2:49 PM, Kelketek Rritaa <[email protected]
<mailto:[email protected]>> wrote:
Urwid has different options for event loops. It offers your choice
of Tornado, Twisted, Glib, a basic Select based loop of its own
creation, and, if I have any say in it, AsyncIO :) It then has a
wrapper class around it. One of the functions is used for scheduling
idle tasks. Glib and Tornado have direct support, the select loop is
its own implementation, so that does, too. In Twisted's case, it's
got a bunch of warnings around it that it's having to hack it in by
doing it every 1/x of a second.
I can certainly come up with a set of minimal changes that will do
this for your review. I should be able to have them done by the end
of the day, and if not, sometime tomorrow. :)
On Feb 27, 2014, at 1:43 PM, Guido van Rossum <[email protected]
<mailto:[email protected]>> wrote:
I see. This could be an issue with anything that's an UI event
loop. However, I would assume that in most cases you would take
the existing UI framework's event loop and wrap an
asyncio-compatible interface around it, rather than taking
asyncio's event loop and augmenting it to support the UI. (Most UI
frameworks are way too complex to replicate, so realistically you
have no choice.)
It sounds as if things are different for curses, which doesn't
really have its own event loop IIRC. (But does Urwid? I know
nothing about it.)
Anyway, I don't want to promise I'll accept a contribution, but I
don't want to reject it unseen either -- can you come up with a
minimal set of changes to asyncio that would implement the feature
you desire? Maybe we can discuss such a patch more easily than I
can understand your Urwid pull request.
On Thu, Feb 27, 2014 at 11:31 AM, Kelketek Rritaa
<[email protected] <mailto:[email protected]>> wrote:
Urwid uses it to refresh the screen. Since curses lets changes
build up until you explicitly call refresh, it's efficient to
do it after all other calls in the loop. But you don't want to
call it after every other single action, and you don't want to
call it just every 1/xth of a second, because it might not
always be needed.
However, if something is changing in an Urwid program, and
that causes an AsyncIO task, chances are the screen needs to
be refreshed. So making sure that the screen always refreshes
when there's a task seems like the right way to do it.
The same principle could be applied to anything with a buffer
that needs to be periodically flushed, but should be flushed
at a fixed interval, and not flushed at the end of every
single task if there's going to be a batch of them in one
iteration of the loop.
On Feb 27, 2014, at 1:12 PM, Guido van Rossum
<[email protected] <mailto:[email protected]>> wrote:
(Redirecting the discussion back to the list.)
On Thu, Feb 27, 2014 at 10:46 AM, Kelketek Rritaa
<[email protected] <mailto:[email protected]>> wrote:
[...]
But yes. I should certainly give examples on when it
might be useful.
Say you're working with another library. You might know
that the library occasionally does something that changes
state, but you either don't trust that library's code to
make that change easily accessed by an AsyncIO task, or
you just find it easier to read and maintain to add an
idle task that occasionally cleans things up or updates
things according to that other library's work.
Alternatively, you might just have cleanup tasks that
need to do x, y, and z, and adding an extra call to the
end of every task to run the cleanup routine would result
in repeated code that could just be taken care of at the
end of the loop.
Hm... Do you have specific examples of these? In either case
it would seem likely that the idle task could do a lot of
extra work -- it will run whenever the loop is about to go
idle, whether or not there is anything to clean up or update.
--
--Guido van Rossum (python.org/~guido
<http://python.org/~guido>)
--
--Guido van Rossum (python.org/~guido <http://python.org/~guido>)
--
Saúl Ibarra Corretgé
bettercallsaghul.com
