This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yselivanov
Recipients asvetlov, ysangkok+launchpad, yselivanov
Date 2018-08-15.17:44:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1534355077.54.0.56676864532.issue34411@psf.upfronthosting.co.za>
In-reply-to
Content
> As far as our experiments show, the requests are blocking each other irrespective of thread pool size. Which is expected since the lock is global across threads.

It looks like you don't understand how GIL works in Python (sorry if I'm mistaken).

The GIL prevents two threads from simultaneously executing *pure Python* code.  Whenever Python code does a system call, the GIL is released for that thread, allowing other Python code in other threads to execute.  Therefore, getaddrname calls in threadpools can't block each other or the event loop thread in any way.

There's a max capacity for the threadpool though, so if you're making 100s of getaddrname calls you'll indeed see some slowdown.  Using IOCP for getaddsname can remove this bottleneck.

> Am I correct in assuming that an implementation for the ProactorEventLoop with IOCP would not require a global lock?

I think so, because we can have as many getaddrcalls as we want all monitored by IOCP for us.  But I'm not an expert in IOCP, so if you want to work on the patch I can't really help you with details.
History
Date User Action Args
2018-08-15 17:44:37yselivanovsetrecipients: + yselivanov, asvetlov, ysangkok+launchpad
2018-08-15 17:44:37yselivanovsetmessageid: <1534355077.54.0.56676864532.issue34411@psf.upfronthosting.co.za>
2018-08-15 17:44:37yselivanovlinkissue34411 messages
2018-08-15 17:44:37yselivanovcreate