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 kristjan.jonsson
Recipients Yury.Selivanov, asvetlov, ebfe, jimjjewett, kristjan.jonsson, lehmannro, pitrou, stutzbach
Date 2010-12-27.02:35:59
SpamBayes Score 0.0017927707
Marked as misclassified No
Message-id <1293417361.45.0.260513769137.issue10576@psf.upfronthosting.co.za>
In-reply-to
Content
1) what I mean is that if a callback rejects GC, the GC algorithm may find its condition for invoking GC in the first place to be still valid immediately afterwards, so doing a GC will be immediately retried.  I have to check, but it could mean that more changes would be required.
2) Of course callbacks have to know, e.g. those that intend to gather statisctic or measure the time of GC.  They have started a timer on the "start" opcode, and expect a "stop" code to follow.  They have to get some "canceled" code for their bookkeeping to work.

Then additionally we have the question: Should you be able to cancel a direct gc request (like calling gc.collect()) or just the automatic one?

This then starts to be a much more complicated change, perhaps one that requires a PEP so I don't think we should do all of that in one gulp.  Once the callback mechanism is in, there is every oppertunity to extend it.
History
Date User Action Args
2010-12-27 02:36:01kristjan.jonssonsetrecipients: + kristjan.jonsson, jimjjewett, pitrou, lehmannro, stutzbach, ebfe, asvetlov, Yury.Selivanov
2010-12-27 02:36:01kristjan.jonssonsetmessageid: <1293417361.45.0.260513769137.issue10576@psf.upfronthosting.co.za>
2010-12-27 02:35:59kristjan.jonssonlinkissue10576 messages
2010-12-27 02:35:59kristjan.jonssoncreate