[issue25920] PyOS_AfterFork should reset socketmodule's lock

STINNER Victor added the comment: If I understood correctly, Python 3.8 and 3.9 binaries provided by python.org is *not* impacted by this issue. Only Python binaries built manually with explicit support for macOS 10.4 ("MAC_OS_X_VERSION_MIN_REQUIRED") were impacted. Python 3.9 and older

[issue25920] PyOS_AfterFork should reset socketmodule's lock

STINNER Victor added the comment: New changeset 0de437de6210c2b32b09d6c47a805b23d023bd59 by Victor Stinner in branch 'master': bpo-25920: Remove socket.getaddrinfo() lock on macOS (GH-20177) https://github.com/python/cpython/commit/0de437de6210c2b32b09d6c47a805b23d023bd59 --

[issue25920] PyOS_AfterFork should reset socketmodule's lock

STINNER Victor added the comment: I wrote PR 20177 to avoid the netdb_lock in socket.getaddrinfo(), but the lock is still used on platforms which don't provide gethostbyname_r(): #if !defined(HAVE_GETHOSTBYNAME_R) && !defined(MS_WINDOWS) # define USE_GETHOSTBYNAME_LOCK #endif --

[issue25920] PyOS_AfterFork should reset socketmodule's lock

Change by STINNER Victor : -- keywords: +patch pull_requests: +19476 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/20177 ___ Python tracker

[issue25920] PyOS_AfterFork should reset socketmodule's lock

Ronald Oussoren added the comment: Technically this would be a functional change, I'd drop this code in 3.9 and trunk (although it is awfully close to the expected date for 3.9b1). Older versions would keep this code and the bug, that way the older python versions can still be used on

[issue25920] PyOS_AfterFork should reset socketmodule's lock

STINNER Victor added the comment: > I'd drop this code instead of fixing it. Hum, FreeBSD, OpenBSD and NetBSD versions which require the fix also look very old. So I agree that it became safe to remove the fix. Would it make sense to only fix it on Python 3.10 and leave other versions with

[issue25920] PyOS_AfterFork should reset socketmodule's lock

Ronald Oussoren added the comment: The macOS test checks if the binary targets macOS 10.4 or earlier. Those versions of macOS have been out of support for a very long time, and we haven't had installers targeting those versions of macOS for a long time as well. 2.7 and 3.5 had installers

[issue25920] PyOS_AfterFork should reset socketmodule's lock

Change by Hugh Redelmeier : -- nosy: +hugh ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25920] PyOS_AfterFork should reset socketmodule's lock

STINNER Victor added the comment: > (I wrote some more details here: > https://emptysqua.re/blog/getaddrinfo-deadlock/ ) On macOS, Python is only affected if "MAC_OS_X_VERSION_MIN_REQUIRED < MAC_OS_X_VERSION_10_5". Is it still the case in 2020? Copy/paste of socketmodule.c: /* On systems

[issue25920] PyOS_AfterFork should reset socketmodule's lock

STINNER Victor added the comment: > Maybe instead of releasing the lock in the forked child process, we should > try to acquire the lock in the os.fork() implementation, and then release it? In bpo-40089, I added _PyThread_at_fork_reinit() for this purpose: reinitialize a lock after a fork

[issue25920] PyOS_AfterFork should reset socketmodule's lock

Terry J. Reedy added the comment: Does the example code (which should be posted here) still hang? If so, automated tests that hang indefinitely on failure are a nuisance. A revised example that failed after, say, a second would be better. -- nosy: +terry.reedy versions: +Python 3.9

[issue25920] PyOS_AfterFork should reset socketmodule's lock

Ronald Oussoren added the comment: #25924 is related to this, I filed this after reading the blog post. The lock might not be necessary on OSX, and possibly on the other systems as well. Yury: resetting the lock in the child should be safe because after the fork the child only has a single

[issue25920] PyOS_AfterFork should reset socketmodule's lock

New submission from A. Jesse Jiryu Davis: On some platforms there's an exclusive lock in socketmodule, used for getaddrinfo, gethostbyname, gethostbyaddr. A thread can hold this lock while another forks, leaving it locked forever in the child process. Calls to these functions in the child

[issue25920] PyOS_AfterFork should reset socketmodule's lock

Changes by Ionel Cristian Mărieș : -- nosy: +ionelmc ___ Python tracker ___ ___

[issue25920] PyOS_AfterFork should reset socketmodule's lock

Yury Selivanov added the comment: Maybe instead of releasing the lock in the forked child process, we should try to acquire the lock in the os.fork() implementation, and then release it? Otherwise, suppose that a call to getaddrinfo (call #1) takes a long amount of time. In the middle of it

[issue25920] PyOS_AfterFork should reset socketmodule's lock

Changes by Yury Selivanov : -- components: +Interpreter Core nosy: +haypo, yselivanov stage: -> needs patch type: -> behavior versions: +Python 3.4, Python 3.5, Python 3.6 ___ Python tracker

[issue25920] PyOS_AfterFork should reset socketmodule's lock

Changes by Yury Selivanov : -- nosy: +serhiy.storchaka ___ Python tracker ___ ___