Re: /bzr/squid3/trunk/ r9573: SourceLayout: acl/, take 1

On 03/15/2009 02:33 AM, Amos Jeffries wrote:
> Tsantilas Christos wrote:
>> For example will not include the acl/Source.o file (included in
>> library acl/libacls.a). This is because there is not direct reference
>> to any of the exported symbols of this object, and the linker believes
>> that this object is not used by squid binary.
>>
> IMO the correct fix for this will be to drop the use of globals as core
> components which magically run everything on program load in some
> undefined order.
> Replacing it with a initialize component which spawns a manager
> component for each module Squid is supposed to run.
>
>
> The presence of this component manager fixed content init function,
> creates the linker dependency needed, and at the same time forms a
> predictable order of creation for each component. Which in turn allows
> magic destruction by a shutdown sequence which can loop over all the
> same components and shut them down in an async loop which turns off as
> much as possible as fast as possible (each component stays active until
> dependencies are all closed and active requests are done or stopped
> somehow)

I did some research and the situation appears to be clear now: The
"Registry" design pattern used by ACLs and some other Squid code is not
going to work "as is" with static libraries. On platforms where
convenience libraries are, essentially, static libraries, the current
"registration" code will not work.

There is nothing wrong with that design as such. In short, GNU linker
and possibly other folks have decided that "static initialization" code
in a static library is not something that should be linked by default.
Since the design relies on static initialization to "register" objects
with Squid, the design does not work.

Our options are:

1) Various fancy linker options and tricks such as --whole-archive.
Simple but probably not portable.

2a) Moving registration code from static libraries to directly linked,
register-this-class object files. Simple but ugly: The result would be
similar to very long lists of source files that we are trying to
eliminate. This is similar to (2b) but on a linker level.

2b) Moving registration code from static libraries to a directly linked,
register-everything object file. Simple but ugly: The whole idea of
registration is to avoid creation of "I know of every class that needs
to be registered" source code. This is similar to (2a) but on a compiler
level.

2c) Replacing implicit registration code with explicit "module"
initialization, including explicit registration of ACL types. This is
what Amos is proposing above, essentially. This option is similar to
option (2b) but the register-everything code would only know about
"modules" and not individual leaf classes used by those modules. We will
probably run into problems with circular dependencies among modules,
which will require splitting modules into several sub-modules, all known
to the init-everything master code (like we had to split acl and auth
libraries).

3) Moving registration code from static libraries to shared libraries. I
am not sure this will work on platforms where shared libraries are not
supported. It also feels wrong because using convenience libraries is
the recommended approach for what we are trying to accomplish, in general.

4) Adding a pure virtual method that must be implemented in all classes
that register themselves. This should force the linker to include object
files defining those virtual methods (and, hence, the registration
code). This sounds simple and localized, but I have not tested it.

I think we should try (4) if it works and do (2c) if it does not.

Option (2c) is useful for non-registration initialization and we already
use that approach for many modules. However, I do not think it is a good
approach for registration of "many little things" that Squid core should
not know about. In other words, (2c) should be reserved for
initialization of modules that Squid code has to know about (by name).

The key question for me right now is how to test this to avoid
committing code that does not link right in some environments. Any
suggestions?

Thank you,

Alex.
Received on Sun Mar 15 2009 - 18:28:08 MDT