Multiprocessing.Manager: fix behavior and doc inconsistencies

[pythonhacker]

BPO	23698
Nosy	@applio
Files	mp_test.py: Test file for demonstrating the above behaviours. Requires psutil module to be installed.

^{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 = None
created_at = <Date 2015-03-18.06:33:05.034>
labels = ['type-bug', 'library', 'docs']
title = 'Multiprocessing.Manager: fix behavior and doc inconsistencies'
updated_at = <Date 2015-05-14.09:47:40.734>
user = 'https://bugs.python.org/pythonhacker'

bugs.python.org fields:

activity = <Date 2015-05-14.09:47:40.734>
actor = 'pythonhacker'
assignee = 'docs@python'
closed = False
closed_date = None
closer = None
components = ['Documentation', 'Library (Lib)']
creation = <Date 2015-03-18.06:33:05.034>
creator = 'pythonhacker'
dependencies = []
files = ['38537']
hgrepos = []
issue_num = 23698
keywords = []
message_count = 5.0
messages = ['238379', '238430', '238524', '238525', '243165']
nosy_count = 4.0
nosy_names = ['pythonhacker', 'docs@python', 'sbt', 'davin']
pr_nums = []
priority = 'normal'
resolution = None
stage = None
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue23698'
versions = ['Python 2.7', 'Python 3.4', 'Python 3.5']

[pythonhacker]

multiprocessing.Manager seems to have an inconsistency in behaviour/documentation or both.

The behaviour inconsistency is documented in the attached test script which should run for both Python2 and Python3.

Briefly, multiprocessing.managers.BaseManager class starts a Python subprocess only after a call to its "start" method. Whereas its subclass, multiprocessing.managers.SyncManager does at the time of object creation. This is undocumented and against the base classe's documented behaviour.

Also, the SyncManager is more commonly advertised via the facade multiprocessing.Manager() which is again at odds with the BaseManager's interface in that,

1. It takes no arguments (Python2) and different arguments (Python 3).
2. You can't call "start" on it but you can call "start" if you initialize it via multiprocessing.managers.SyncManager directly (!)
3. Even if you can't call a start on it, apparently you can shut it down via a call to "shutdown"
4. When you try to start such a manager you get a strange AssertionError complaining the state is not INITIAL. A better error is required here.

Please find the attached file for all the sequence of tests done.

Suggested changes are,

1. Fix the inconsistency in documented behaviour between SyncManager and its base class. Either don't start the child process upon object creation or document it.
2. Fix the inconsistency in SyncManager object creation interface and behaviour via "mulitprocessing.Manager()" and directly via "multiprocessing.managers.SyncManager(...)" . One should be able to start both objects cleanly. And the former should also take the address argument. If not document it properly.
3. The AssertionError when trying to start the SyncManager object obtained via a call to "multiprocessing.Manager()" looks like a bug. It should be fixed - otherwise a bette error should be raised and documentation updated.

[applio]

This is closely related to bpo-23510. The two issues are reacting to the same underlying inconsistency though in this issue the problem is more generally (and clearly) stated whereas bpo-23510 is more concerned with the consequences to using these as Context Managers.

The solution that gets implemented here should address both issues.

As mentioned in bpo-23510, I have a working fix though am looking for ways to further minimize the impact to existing code that uses Manager/SyncManager -- simply documenting the current inconsistent state is inadequate.

[pythonhacker]

Is your patch uploaded anywhere ?

Anyway, before thinking whether this should be a patch or doc fix, one needs multiprocessing module author to possibly comment on the right behaviour expected here.

[applio]

No, it's premature to share the start of my patch.

Very much agreed on getting that input/insight -- sbt (multiprocessing module maintainer and original author) was added to the nosy list yesterday too.

[pythonhacker]

@sbt - Any comments on this ?