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 mark.dickinson
Recipients benjamin.peterson, donmez, jnoller, mark.dickinson
Date 2008-08-07.01:33:31
SpamBayes Score 0.008251709
Marked as misclassified No
Message-id <1218072813.77.0.810340057612.issue3419@psf.upfronthosting.co.za>
In-reply-to
Content
Here's what's going on with the incref error:

Look in the Server class, in managers.py:  consider a shared object with 
id 'id'.  When a reference to the shared object is created, its id is 
added to the id_to_refcount dictionary:

{id: None}

and *shortly afterwards*, the refcount is incremented to get:

{id: 1}

When the object is deleted or goes out of scope later on, the refcount 
is decref'd, and id is removed entirely from id_to_refcount.

The problem occurs when there are two processes simultaneously asking 
for access to the same object.  If a second process happens to decref 
'id' in between the first process creating the reference and 
incrementing it, then the incref from the first process will fail.  This 
is exactly what's happening (some of the time) in test_remote in the 
test_suite.  The failing sequence of operations is:

initial state:         id not in id_to_refcount
(process 1): create    id_to_refcount[id] is None
(process 1): incref    id_to_refcount[id] == 1
(process 2): create    id_to_refcount[id] == 1
(process 1): decref    id not in id_to_refcount
(process 2): incref    KeyError!
(process 2): decref    (never get here...)

I'm not really familiar enough with the whole multiprocessing module to 
know what the right fix for this is.
History
Date User Action Args
2008-08-07 01:33:34mark.dickinsonsetrecipients: + mark.dickinson, donmez, benjamin.peterson, jnoller
2008-08-07 01:33:33mark.dickinsonsetmessageid: <1218072813.77.0.810340057612.issue3419@psf.upfronthosting.co.za>
2008-08-07 01:33:32mark.dickinsonlinkissue3419 messages
2008-08-07 01:33:31mark.dickinsoncreate