Message124698
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. |
|
Date |
User |
Action |
Args |
2010-12-27 02:36:01 | kristjan.jonsson | set | recipients:
+ kristjan.jonsson, jimjjewett, pitrou, lehmannro, stutzbach, ebfe, asvetlov, Yury.Selivanov |
2010-12-27 02:36:01 | kristjan.jonsson | set | messageid: <1293417361.45.0.260513769137.issue10576@psf.upfronthosting.co.za> |
2010-12-27 02:35:59 | kristjan.jonsson | link | issue10576 messages |
2010-12-27 02:35:59 | kristjan.jonsson | create | |
|