Ah, my mistake. I suppose Tornado doesn't have that functionality. Anyhow, I've made some changes here to demonstrate:
http://code.google.com/r/kelketek-tulip-contribution/source/diff?spec=svnebd522e3a247104ab1caeee74875aff049f9f74d&r=ebd522e3a247104ab1caeee74875aff049f9f74d&format=side&path=/asyncio/base_events.py As requested, they're just minimal ones to show what would be needed to do this. It's not much, though if we moved forward with this, I'd need to write a few test cases as well. Even if this doesn't turn out to be a good fit, I thank you for considering it. On Feb 27, 2014, at 3:05 PM, Saúl Ibarra Corretgé <[email protected]> wrote: > 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
