On Aug 3, 2014, at 21:50 , Marvin Humphrey <[email protected]> wrote:
> 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? Of course, we can agree on that. I’d only like to add that I see this approach simply as a Perl-only fix. Other host languages should stick with a single per-process class registry. I don’t see a problem with using different approaches to threading for different languages. Perl’s threading model is a bit special and it’s extremely hard to make it play nicely with objects that wrap C pointers. For now, I’d be happy with a solution that allows to use Clownfish objects in a completely isolated way within a Perl thread. Cloning the class registry is a straight-forward solution and I don’t see how it would throw anything away or change the guarantees we make for other host languages. It also requires no changes to other parts of the code and doesn’t cause any performance loss. I haven’t thought it through yet, but I think with a cloned class registry, we don’t need any special handling of refcounts of immortal objects. So we might be able to remove the refcount methods as well. But I never understood exactly why the refcount hack is needed at all. Nick
