Skip to content

xmlrpclib.make_connection() is not thread safe #51156

Closed

Description

@vstinner
BPO 6907
Nosy @kristjanvalur, @vstinner

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2009-09-14.11:15:21.189>
created_at = <Date 2009-09-14.10:20:20.134>
labels = ['extension-modules', 'type-bug', 'invalid']
title = 'xmlrpclib.make_connection() is not thread safe'
updated_at = <Date 2009-09-15.21:28:47.117>
user = 'https://github.com/vstinner'

bugs.python.org fields:

activity = <Date 2009-09-15.21:28:47.117>
actor = 'kristjan.jonsson'
assignee = 'none'
closed = True
closed_date = <Date 2009-09-14.11:15:21.189>
closer = 'vstinner'
components = ['Extension Modules']
creation = <Date 2009-09-14.10:20:20.134>
creator = 'vstinner'
dependencies = []
files = []
hgrepos = []
issue_num = 6907
keywords = []
message_count = 4.0
messages = ['92596', '92603', '92605', '92657']
nosy_count = 2.0
nosy_names = ['kristjan.jonsson', 'vstinner']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue6907'
versions = ['Python 2.7', 'Python 3.2']

Activity

  1. vstinner commented on Sep 14, 2009

    @vstinner
    MemberAuthor

    The issue bpo-6099 (part of bpo-6267 superset) introduced a regression:
    xmlrpclib.make_connection() is not thread safe. If xmlrpclib is used in two
    threads, the socket is shared, but it doesn't any lock, and so data will be
    mixed between the two requets. It becomes worse when I use SSL (pyopenssl
    or m2crypto).

    A possible solution is to use a different socket for each thread.

    Note: I really love bpo-6099, it was exactly what I needed :-)

  2. kristjanvalur commented on Sep 14, 2009

    kristjanvalurmannequin
    Mannequin

    the xmlrpclib.ServerProxy is not thread safe, no. Nor is it designed to
    be. the documentation never claims that it is and the fact that the old
    version was (due to a new HTTPConnection being created each time) is a
    coincidence than a design feature.
    In my own client code I use a pool of ServerProxy objects for each
    thread to claim and use one at a time. This way I can have many
    simultaneous requests to the same server going.
    You can also create your own lock and share a ServerProxy among threads.

    Also note that HTTPConnection is not thread safe either. And in
    general, class instances in the lib are not thread safe unless
    explicitly documented to be so.

  3. vstinner commented on Sep 14, 2009

    @vstinner
    MemberAuthor

    @krisvale: You changed the resolution to invalid, but you leaved the state
    unchanged (open). Ok, I agree that the stdlib is not thread safe, and so I
    closed this issue.

    I saw this issue as a regression because the previous version (using a different
    socket for each XML-RPC request) was thread sae (even if it wasn't designed
    to be thread safe) :-)

  4. kristjanvalur commented on Sep 15, 2009

    kristjanvalurmannequin
    Mannequin

    Ah yes.
    Sorry, I'm no good with this system. Thanks.

  5. transferred this issue fromon Apr 10, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    extension-modulesC modules in the Modules dirtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions