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 dwfreed
Recipients dwfreed
Date 2017-05-26.09:32:15
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
On at least Linux (and probably most other UNIXes, except OS X), the C functions getservbyname(), getservbyport(), and getprotobyname() are not threadsafe.  CPython's wrappers around these functions in the socket module do nothing to cover up this fact.  Simple reproduction script for getservbyname (others similar):

import threading
import socket

def getservbyname_loop(service, port):
        while True:
                result = socket.getservbyname(service)
                if result != port:
                        raise RuntimeError("thread-safety broken, got %d, expected %d" % (result, port))

thread1 = threading.Thread(target=getservbyname_loop, args=("ssh", 22))
thread2 = threading.Thread(target=getservbyname_loop, args=("smtp", 25))

One of the threads will throw the RuntimeError, saying it got the port number the other thread should have gotten.

Naive fix: a lock (eg, just use the netdb_lock already created in the module)

Proper fix: use the libc's reentrant variant if available, and fall back to locking if not (see gethostbyname_ex() implementation for example).

I'd be happy to work on this, but as I don't have access to anything other than Linux and OS X at the moment, it would be helpful if platform maintainers could chime in on what if any reentrant variants of these functions exist on their platforms so we can have a more proper fix.
Date User Action Args
2017-05-26 09:32:15dwfreedsetrecipients: + dwfreed
2017-05-26 09:32:15dwfreedsetmessageid: <>
2017-05-26 09:32:15dwfreedlinkissue30482 messages
2017-05-26 09:32:15dwfreedcreate