On Sun, Aug 3, 2014 at 9:12 AM, Nick Wellnhofer <[email protected]> wrote: > On Aug 3, 2014, at 11:41 , Nick Wellnhofer <[email protected]> wrote: > >> Another approach is to clone the class registry for every Perl thread. >> Something like that should work: >> >> - Store the class registry in a Perl global. This would mean we need a >> host-specific function to fetch the registry. >> - Define the special CLONE method which is invoked whenever Perl creates >> a new thread. This method would clone the registry and store it in the >> new thread’s version of the global variable. >> >> Then we wouldn’t have to care about thread-safety of refcount handling at >> all. > > I implemented this approach in branch ‘clone_class_registry’.
Hmm. I'm sorry but I'm not a fan of this approach, which throws away hard-won invariants in the current codebase and conflicts with the philosophy which undergirds the class registry: our OO infrastructure is thread-safe even though most objects are not. We've gone to a lot of trouble to guarantee that Class objects will always be true global singletons -- that there will always be one and only one Class object per process for a given class, across all threads. If we can no longer count on that, reasoning about concurrency becomes much harder. We are precluded from doing things like returning an object from a child thread to a parent thread: 1. Child thread spawned. 2. FooJr class initialized in child thread. 3. FooJr object returned to parent thread. 4. FooJr class initialized in parent thread. 5. Now FooJr_Equals() fails, FooJr_Is_A() fails. There are probably other subtle bugs lurking. Non-constant global variables are evil. Singleton initialization is a notorious problem area. Meanwhile, there is a competing approach (per-object flags) which might not only address these thread-safety issues, but allow us to remove several methods from Obj. I'm comfortable with making the Lucy 0.4.0 release without these thread-safety fixes, and I was willing to put off discussing per-object flags at your request. I think it's important to evaluate that approach before proceeding... but can we agree to do nothing for the time being? Marvin Humphrey
