On Mon, Sep 17, 2012 at 8:23 AM, Kurt Starsinic <[email protected]> wrote:
> I'm curious as to what the instant problem is. I'm familiar with
> fragile base class becoming an issue in a few cases:
>
> 1) We're handing out headers + precompiled libraries to end users.
> They're going to build subclasses, and later they might re-link their
> applications with newer versions of the libraries, having skipped
> re-compilation in error. Boom.
> Which of these (or which other scenarios) are we running into?
The first case is the one we're concerned about.
It is possible to write pure Perl subclasses of Lucy classes, and this works
well for things like QueryParser which are not performance bottlenecks.
However it doesn't work so well for classes like Matchers which have methods
which are invoked once per matching document during a search. The method call
overhead is too high and so the subclasses do not scale well to large
collections.
The solution, we believe, is to publish a C API which allows users to create
compiled subclasses. Right now in our (prototype) API, superclass struct
definitions are exposed and subclasses must use them to compose their own
struct definitions. This makes these compiled subclasses vulnerable to
"fragile base class" problems should a superclass be recompiled with added,
removed, or reordered member variables.
The problem is particularly pernicious because of what it means to "re-link" a
Perl application. If the user upgrades Lucy using the CPAN apparatus, the
packaging system does not know that it needs to force re-compilation and
re-installation for downstream modules which depend on Lucy's ABI.
The "re-link" stage happens dynamically, at run-time:
use Lucy;
use LucyX::Analysis::WhitespaceTokenizer;
If the composition of the member variables in any of WhitespaceTokenizer's
superclasses has changed, the app will likely segfault as soon as a
WhitespaceTokenizer is created or used.
That's not acceptable, and that's why it's important to solve the issue now
before we publish an API which exposes our users to a fragile base class
problem.
Marvin Humphrey
