homepage

I am attempting to create a multiprocessing.SyncManager subclass
instance, register a test class with it, start the manager, and
instantiate the test class. The example I'm providing here is basically
equivalent, and illustrates the same problem (example code is at the
bottom of this message).
This works without issue as long as the manager is started in the file
you actually invoke from the command line. Handled in exactly the same
way, however, with the call to the SyncManager instance's start method
made in an included file, attempting to instantiate anything, including
built-in list() and dict() objects, via the manager causes script to
hang indefinitely.
Output on ctrl+c breaking seems to indicate the call may be hanging in
the challenge process.
Invocation and output (starting/started are wrapped around the start()
call; creating/created are wrapped around the manager's registered
object instantiation):
$ python test.py 
starting...
...started
creating...
^CTraceback (most recent call last):
 File "test.py", line 6, in <module>
 obj = test_manager.TC()
 File "/usr/lib64/python2.6/multiprocessing/managers.py", line 634, in temp
 token, exp = self._create(typeid, *args, **kwds)
 File "/usr/lib64/python2.6/multiprocessing/managers.py", line 532, in
_create
 conn = self._Client(self._address, authkey=self._authkey)
 File "/usr/lib64/python2.6/multiprocessing/connection.py", line 140,
in Client
 answer_challenge(c, authkey)
 File "/usr/lib64/python2.6/multiprocessing/connection.py", line 372,
in answer_challenge
 message = connection.recv_bytes(256) # reject large message
KeyboardInterrupt
test.py:
from test_inc import test_manager
print "creating..."
obj = test_manager.dict()
print "...created"
test_inc.py:
from multiprocessing.managers import SyncManager
test_manager = SyncManager()	
print "starting..."
test_manager.start()
print "...started"
Environment: Linux 2.6.28-gentoo-r5 #4 SMP x86_64 Intel(R) Core(TM)2 Duo
CPU T5470 @ 1.60GHz GenuineIntel GNU/Linux
Version: Python 2.6.4
Apologies if this is my failure to understand how the library (or even
Python) works, but it seems quite odd that this would be expected behavior.

I can't seem to reproduce this on trunk...

Tested in 2.6.6 on Gentoo and 2.7.1 on Ubuntu (Server); this behavior is no longer present when using the provided code.
Hopefully this means the original issue has been solved; I haven't touched the code that revealed it since around the time I filed this originally.
If someone can confirm that the test code works in whatever versions of Python 3 are current, please go ahead and close this.