On 9/14/07, Jean-Paul Calderone <exarkun at divmod.com> wrote: > On Fri, 14 Sep 2007 17:43:39 -0400, James Y Knight <foom at fuhm.net> wrote: > > > >On Sep 14, 2007, at 3:30 PM, Jean-Paul Calderone wrote: > >>On Fri, 14 Sep 2007 14:13:47 -0500, Justin Tulloss <tulloss2 at uiuc.edu> > >>wrote: > >>>Your idea can be combined with the maxint/2 initial refcount for > >>>>non-disposable objects, which should about eliminate thread-count > >>>>updates > >>>>for them. > >>>>-- > >>> > >>>I don't really like the maxint/2 idea because it requires us to > >>>differentiate between globals and everything else. Plus, it's a hack. I'd > >>>like a more elegant solution if possible. > >> > >>It's not really a solution either. If your program runs for a couple > >>minutes and then exits, maybe it won't trigger some catastrophic behavior > >>from this hack, but if you have a long running process then you're almost > >>certain to be screwed over by this (it wouldn't even have to be *very* > >>long running - a month or two could do it on a 32bit platform). > > > >Not true: the refcount becoming 0 only calls a dealloc function.. For > >objects which are not deletable, the dealloc function should simply set the > >refcount back to maxint/2. Done. > > > > So, eg, replace the Py_FatalError in none_dealloc with an assignment to > ob_refcnt? Good point, sounds like it could work (I'm pretty sure you > know more about deallocation in CPython than I :). As I've said, this is all moot. The cache coherence protocols on x86 means this will be nearly as slow as proper atomic refcounting, and will not scale if multiple threads regularly touch the object. My experience is that they will touch it regularly. -- Adam Olsen, aka Rhamphoryncus
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4