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, roudkerk
Date 2008-08-17.13:29:23
SpamBayes Score 8.6579166e-07
Marked as misclassified No
Message-id <1218979766.84.0.0749638339208.issue3419@psf.upfronthosting.co.za>
In-reply-to
Content
Here's a patch that fixes the incref problem for me.  This *definitely* 
needs review from someone more familiar with the multiprocessing module 
than I am;  I'm not at all confident that it won't break something else.

The original problem:  the Server.create method creates shared objects 
with an effective reference count of 0, making them vulnerable to 
premature garbage collection.

The solution in the patch: create shared objects with a reference count 
of 1, and make it the responsibility of the caller of Server.create() to 
do a decref later (once a ProxyObject for the created shared object has 
been initialized).   In effect, Server.create creates and returns a 
reference, and the caller then owns that reference and is responsible 
for disposing of it.
History
Date User Action Args
2008-08-17 13:29:27mark.dickinsonsetrecipients: + mark.dickinson, donmez, roudkerk, benjamin.peterson, jnoller
2008-08-17 13:29:26mark.dickinsonsetmessageid: <1218979766.84.0.0749638339208.issue3419@psf.upfronthosting.co.za>
2008-08-17 13:29:25mark.dickinsonlinkissue3419 messages
2008-08-17 13:29:25mark.dickinsoncreate