[issue33063] failed to build _ctypes: undefined reference to `ffi_closure_FASTCALL'

Change by Fantix King : -- nosy: +fantix nosy_count: 3.0 -> 4.0 pull_requests: +25844 stage: -> patch review pull_request: https://github.com/python/cpython/pull/8620 ___ Python tracker <https://bugs.python.org/i

[issue39951] Ignore specific errors when closing ssl connections

Fantix King added the comment: This should/will be fixed by GH-17975 I think - like suggested in the OpenSSL comments, the proposed change will always try to run SSL_read() before SSL_shutdown(), even after the close_notify is sent. -- nosy: +fantix

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Change by Fantix King : -- pull_requests: +20057 pull_request: https://github.com/python/cpython/pull/20868 ___ Python tracker <https://bugs.python.org/issue30

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Fantix King added the comment: and yes, updated the SO_SNDBUF too -- ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailin

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Fantix King added the comment: OK I think I solved the problem by improving the two loops using smarter buffer sizes: # fill the buffer until sending 5 chars would block size = 8192 while size > 5: with self.assertRaises(BlockingIOEr

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Fantix King added the comment: Oh thank you for the clue, that's super helpful! Let me try locally. This fix PR was originally done to solve a hanging call in a race condition, so the test would hang forever if the fix is not working as expected. The 10 seconds wait_for() is to make sure

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Fantix King added the comment: I've been testing on local VMs with Gentoo and Ubuntu, but the issue cannot be reproduced. The error log is not really revealing anything useful, other than that the send was blocked when it was supposed to be successful. As it is not constantly failing

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Fantix King added the comment: I'm checking now -- ___ Python tracker <https://bugs.python.org/issue30064> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Fantix King added the comment: Thanks for the comments! Added PR 20494 to properly fix/skip the test for (hopefully) all platforms. -- ___ Python tracker <https://bugs.python.org/issue30

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Change by Fantix King : -- pull_requests: +19743 pull_request: https://github.com/python/cpython/pull/20494 ___ Python tracker <https://bugs.python.org/issue30

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Fantix King added the comment: Not a simple one - FreeBSD is returning ECONNREFUSED immediately when trying to connect to a non-listening port on the loopback address: https://lists.freebsd.org/pipermail/freebsd-current/2005-May/049876.html Then all following connect attempts on the same

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Fantix King added the comment: Ouch ... looks like FreeBSD also needs a few more retries than a single retry. I'll test on a FreeBSD and create a PR for that. -- ___ Python tracker <https://bugs.python.org/issue30

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Change by Fantix King : -- pull_requests: +19633 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20369 ___ Python tracker <https://bugs.python.org/issu

[issue30064] BaseSelectorEventLoop.sock_{recv, sendall}() don't remove their callbacks when canceled

Fantix King added the comment: Following the discussion - looks like `add_reader()` will cancel the previous `handle` on the same `fd` if found, so I think it is reasonable to solve this cancellation-race issue by checking if the `handle` is cancelled as shown in the attached patch (tests

[issue33840] connection limit on listening socket in asyncio

Change by Fantix King : -- nosy: +fantix ___ Python tracker <https://bugs.python.org/issue33840> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue37179] asyncio loop.start_tls() provide support for TLS in TLS

Change by Fantix King : -- nosy: +fantix ___ Python tracker <https://bugs.python.org/issue37179> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34745] asyncio ssl memory leak

Change by Fantix King : -- pull_requests: +12348 ___ Python tracker <https://bugs.python.org/issue34745> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34745] asyncio ssl memory leak

Change by Fantix King : -- keywords: +patch pull_requests: +12343 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34745> ___ ___ Py

[issue34745] asyncio ssl memory leak

Change by Fantix King : -- nosy: +fantix ___ Python tracker <https://bugs.python.org/issue34745> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34847] asyncio: Add PHA for TLS 1.3

New submission from Fantix King : This was raised in GH-9460 where the same post handshake authentication (PHA) was added to the ssl module. It should be added to asyncio too. This issue is to discuss the design of PHA API in asyncio, and implement it in Python 3.8. One approach is to add

[issue33062] ssl_renegotiate() doesn't seem to be exposed

Change by Fantix King : -- nosy: +fantix ___ Python tracker <https://bugs.python.org/issue33062> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33062] ssl_renegotiate() doesn't seem to be exposed

Change by Fantix King : -- keywords: +patch pull_requests: +8125 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33062> ___ ___ Py

[issue23794] http package should support HTTP/2

Changes by Fantix King <fantix.k...@gmail.com>: -- nosy: +Fantix King ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue23794> ___ _

[issue1432] Strange behavior of urlparse.urljoin

Fantix King added the comment: This issue also causes similar behavior on some libraries like mechanize which depend on urljoin -- nosy: +fantix __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1432