On 04/08/2014 04:50, Marvin Humphrey wrote:
On Sun, Aug 3, 2014 at 3:20 PM, Nick Wellnhofer <[email protected]> wrote:
But I never understood exactly why the refcount hack is needed at all.
These days, the custom refcounting methods on Class, HashTombStone and
RawPosting faciliate two objectives: compatibility with threads, and speed.
For the sake of compatibility with threads, we made two changes a while back:
* Eliminate refcounting of Class ("VTable" at the time).
* Use LockFreeRegistry instead of Hash for the Clownfish class registry.
After those changes, you still couldn't share Clownfish-based objects across
threads, but basic object creation and destruction were now possible without
refcount race conditions on elements of the global OO infrastructure.
OK, then let's discuss the immortal flag.
To protect against refcount races on the Perl side, objects are shared using
SvSHARE, right? So if a host object is created and the immortal flag is set,
it could be shared automatically. This eliminates the need to override To_Host.
To set the immortal flag, a simple function like Obj_make_immortal would be
enough. This should be called immediately after object creation. We wouldn't
even need a flag but only a special value like -1 in ref.count.
Shouldn't be hard to implement.
Then I'd like to salvage most commits from the clone_class_registry branch:
- Make String#Clone create a new String object
This removes an optimization that immutable strings made possible. But
especially with regard to threads, I think it's important that String#Clone
really creates a new object and doesn't just increment the refcount.
- Special case String hash keys
To make up for the commit above.
- Implement Method#Clone
- Make sure to clone a Class's methods
Not strictly needed right now but a good precaution.
- Implement LFReg#Clone
- Implement iterator for LockFreeRegistry
Especially the latter might be useful later.
Nick
