At 11:42 AM 10/31/03 +0000, Michael Hudson wrote: >"Brett C." <bac at OCF.Berkeley.EDU> writes: > > >> I take it from your posting of last week that you've thought about > >> other ways of implementing exception handling? I guess a > >> non-reference count based GC is a prerequisite for that... > >> > > > > Yeah, I have tossed the exception handling idea around in my head a > > little, but the culmination was what I posted. > > > > And a non-refcount GC would definitely help, even if the exception > > handling wasn't changed. More places where you could just return NULL > > instead of having to deal with DECREFing objects. > >And reducing the memory overhead of objects. OTOH, maybe you could see whether INCREF/DECREF can be used to control synchronization of objects between threads, and thus get a multiprocessor Python. Note that if an object's refcount is 1, it's not being shared between threads. INCREF could be looked at as, "I'm about to use this object", so if the object isn't "owned" by the current thread, then lock it and increment an ownership count. Or was that how the experimental free-threading Python worked? >Here's my crazy idea that's been knocking around my head for a while. >I wonder if anyone can shoot in down in flames. > >Remove the ob_type field from all PyObjects. Make pymalloc mandatory, >make it use type specific pools and store a pointer to the type object >at the start of each pool. How would you get from the pointer to the pool head?
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