[issue44951] selector.EpollSelector: EPOLLEXCLUSIVE, round 2
David Gilman added the comment: Reflecting on this a bit I wonder if the best of all worlds is to have an EpollExclusiveSelector whose modify() implementation just unregisters and registers the file descriptor. -- ___ Python tracker <https://bugs.python.org/issue44951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44951] selector.EpollSelector: EPOLLEXCLUSIVE, round 2
David Gilman added the comment: I also played with making another whole subclass that has it on by default, see this package https://github.com/dgilman/selector-epoll-exclusive That class could have EPOLLEXCLUSIVE on by default but could raise NotImplemented if you try and modify() it. Putting it in as a second class means you can also drop it into existing code unmodified, something that will play very nicely with all existing users of selector. -- ___ Python tracker <https://bugs.python.org/issue44951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44951] selector.EpollSelector: EPOLLEXCLUSIVE, round 2
Change by David Gilman : -- keywords: +patch pull_requests: +26284 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27819 ___ Python tracker <https://bugs.python.org/issue44951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44951] selector.EpollSelector: EPOLLEXCLUSIVE, round 2
New submission from David Gilman : Note that this is a different approach from the one taken in https://bugs.python.org/issue35517 although the issue is still the same. I've written a patch that allows users of selector.EpollSelector to enable EPOLLEXCLUSIVE on their file descriptors. This PR adds a setter and read only property to only the EpollSelector class instead of trying to expand the entire selector API like the other patch. The other discussion mentioned that there are some useful flags that could be passed down like this one. If other useful behavioral flags emerged in the future I think they should get their own API similar to how I've done it here. However, the other flags available so far for epoll are not useful for the selector module: EPOLLONESHOT and EPOLLET are incompatible with the design of the selector API and EPOLLWAKEUP is only marginally useful, not even getting exported into the select module after nearly a decade (Linux 3.5 was released in 2012). My API uses a getter/method instead of a read/write property because my understanding is that property access shouldn't raise exceptions, but if that doesn't matter here, it could be a read/write property. Justification: First, this is a useful flag that improves performance of epoll under even moderate load. I was going to turn it on by default in this patch but unfortunately Linux prevents you from doing epoll_mod() on anything that has EPOLLEXCLUSIVE set on it, breaking the python-level API. With this patch if you try to modify() after EPOLLEXCLUSIVE is set you'll get an EINVAL but I think the trade-off here is worth it. You don't enable EPOLLEXCLUSIVE on accident and you're reading the manpage for EPOLLEXCLUSIVE where this exact behavior is mentioned before turning anything on, right? And of course the Python docs also warn you about modify(). Second, the thundering herd problem solved by EPOLLEXCLUSIVE is somewhat of a sore spot for Python's PR. In the past year two widely disseminated articles have brought up this issue. This PR isn't going to be a silver bullet however it can make a huge impact in gunicorn, the 3rd party library mentioned in both articles. Gunicorn is a popular WSGI web server and its gthread worker (not the default but the one most often used in production) directly uses the selector module from the standard library. Honestly, it's pretty cool that they were able to make such efficient use of a standard library module like this - how far we've come from the days of asynchat! There is nothing in gunicorn's threaded worker that calls modify() so there would be no API breakage there. Gunicorn thundering herd articles: https://blog.clubhouse.com/reining-in-the-thundering-herd-with-django-and-gunicorn/ https://rachelbythebay.com/w/2020/03/07/costly/ -- components: Library (Lib) messages: 399880 nosy: David.Gilman priority: normal severity: normal status: open title: selector.EpollSelector: EPOLLEXCLUSIVE, round 2 ___ Python tracker <https://bugs.python.org/issue44951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22392] Clarify documentation of __getinitargs__
New submission from David Gilman: Implementations of __getinitargs__ return a tuple of the positional arguments for __init__. This wasn't initially apparent to me after reading the docs: I thought you were passing a tuple (args, kwargs) that would get called f(*args, **kwargs) and had to go to the pickle implementation to find out what you were supposed to do. The proposed documentation enhancement: mention that you're just supposed to return a tuple of positional args and that it doesn't support kwargs. -- assignee: docs@python components: Documentation messages: 226795 nosy: David.Gilman, docs@python priority: normal severity: normal status: open title: Clarify documentation of __getinitargs__ type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22392 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18040] SIGINT catching regression on windows in 2.7
David Gilman added the comment: So the original motivation here was to piggyback on SIGINT in order to do something like this on Windows: http://stackoverflow.com/questions/132058/showing-the-stack-trace-from-a-running-python-application I've given Tim's patch a shot and I see that I've been barking up the wrong tree. I agree that this one-liner is a kinda invasive change and probably isn't worth putting in a point release. Thanks for the help. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18040] SIGINT catching regression on windows in 2.7
New submission from David Gilman: I opened this StackOverflow bug with an example simplified testcase. As you can see in the first comment a user added that this code worked under Python 2.6 on Windows and no longer works on 2.7. http://stackoverflow.com/questions/16686510/how-do-i-capture-sigint-in-python-on-windows?noredirect=1#comment24013681_16686510 Here's a patch that went into the 2.7 release that maybe is related? http://bugs.python.org/issue1677 -- messages: 189843 nosy: David.Gilman priority: normal severity: normal status: open title: SIGINT catching regression on windows in 2.7 versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18040 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com