Christian Heimes added the comment: > For this patch, I don't see the benefit of putting it in the select > module, instead of a separate module. Is there a specific reason?
There is at least one, but probably several other modules named "epoll" or "_epoll" in the wild. These modules implement an epoll interface with Pyrex, ctypes or C. All of them have a slightly different API. I don't want to break 3rd party software. The select module already contains an interface to select and poll. IMO it's the best place. > Looking at the code, I don't have many remarks. pyepoll_new may leak > if epoll_create fails. I think that allowing threading around > epoll_ctl is useless, but I may be wrong. Thanks, I've fixed the problem in pyepoll_new. The Linux kernel protects every call to epoll_ctl with a mutex. It *could* block and therefor I'm allowing threads around the epoll_ctl() call. __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1657> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
