Steve Dower added the comment: It looks like Modules/selectmodule.c already has the handling for when this gets large (and we really want to stop allocating the static array on the stack), which is a plus, but I'd want to see the performance cost to small selects if suddenly we're allocating 100s of KB on the heap rather than small and cheap stack allocations.
For the amount of work going on here for each select() call, Victor is right - you're going to get severely diminishing returns as this increases in size. However, I see no reason why this couldn't be totally dynamic, at least on Windows. Redefining that value just changes a static array definition, but the array size never gets passed in to the OS AFAICT, so there's no reason we couldn't stack allocate for small select()s and heap allocate for big select()s. That's considerably more work than anyone had in mind, I'd wager. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28708> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
