On 5/24/2012 2:40 PM, Giampaolo RodolĂ wrote:
It's not clear to me what such a PEP should address in particular, anyway here's a bunch of semi-random ideas.
I have been reading for perhaps a decade how bad asyncore is. So I hope you stick with trying to thrash out something different, even if the discussion gets tedious or contentions.
=== Idea #1 ===
4 classes (SelectPoller, PollPoller, EpollPoller, KqueuePoller) within concurrent.eventloop namespace all sharing the same API:
For new classes, the first question is what concept (and data/function grouping) they and their instances represent. As a naive event loop user, I might think in terms of event sources (or sets of sources) and corresponding handlers. For events generated by 'file' polling, the particular method would seem like a secondary issue. Your proposed classes are named after methods and you give no initialization api. This suggests to me that you mean for all files being polled by the same method to be grouped together. If so, there would only need 0 or 1 instance of each 'class', in while case, they could just as well be modules. In other words, I am unsure what concept these classes would represent. I am perhaps thinking at too high a level.
- register(fd, events, callback) # callback gets called with events as arg - modify(fd, events) - unregister(fd) - call_later(timeout, callback, errback=None) - call_every(timeout, callback, errback=None) - poll(timeout=1.0, blocking=True) - close()
call_later() and call_every() can return an object having cancel() and reset() methods.
-- Terry Jan Reedy