On Thu, Feb 12, 2015 at 4:27 AM, Nick Wellnhofer <[email protected]> wrote: > On 11/02/2015 05:13, Marvin Humphrey wrote:
>> I've added a new commit on that branch which implements your >> suggestion (updating the pull request): >> >> >> https://github.com/rectang/lucy-clownfish/commit/c0b90906746d3825e3fc9fd41d023aa727e07b13 > > > Nice. OK, cool -- I'm going to merge these two pull requests to the lucy and clownfish master branches today, then. > Another question: Do we really need the "thread-safe but not immortal" > distinction for LFReg? FWIW, there's zero cost difference whether it's in that group or another, and it's not technically immortal. If it had gone in the "immortal" group, that group would have needed another name. Calling attention to its special status was somewhat deliberate. ;) > If we keep LFReg as an implementation detail, we > could just treat it as an immortal class. This would simplify things as we > wouldn't need atomic operations for refcount handling. (We probably never > incref the class registry anyway.) It would simplify bootstrapping if it wasn't even a Clownfish data structure, so that it didn't need method calls or object initialization. I'm having to insert some fragile hacks in the Python bindings because of mutual dependencies between Python type and module objects plus Class, Method, LockFreeRegistry, and String during boot. > As a side note, our immutable String class is "thread-safe but not > immortal", too. We could make it completely thread-safe with atomic refcount > operations. But I wouldn't want to go down that way, since atomic operations > are rather costly. I contemplated special-casing String's refcounting and reached the same conclusion. Marvin Humphrey
