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

Tsantilas Christos wrote:
> Hi,
> maybe the use of static libraries is not good idea. Currently I am not
> able to correctly linking the squid3. The linker will not include in
> main executable file important obj's.
> 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.
>
> A solution is to link with the "--whole-archive" linker option but
> looks very difficult to use this option with libtool
> An other solution is to do objects initiation in a .cc file which will
> be included directly to squid binary.
> Also maybe using dynamics libraries is a solution.
>
> Regards,
> Christos
>
>
> Alex Rousskov wrote:
>> ------------------------------------------------------------
>> revno: 9573
>> committer: Alex Rousskov <rousskov_at_measurement-factory.com>
>> branch nick: trunk
>> timestamp: Fri 2009-03-13 15:05:54 -0600
>> message:
>> SourceLayout: acl/, take 1
>> Moved src/ACL* and a few related files into src/acl/.
>> Renamed ACL source files from ACLFoo.{cc,cci,h} to Foo.{cc,cci,h}.
>> Added acl/ libraries, reorganized auth/ libraries, and split
>> ACLChecklist
>> class to avoid circular dependencies among libraries.
>> Many targets in src/Makefile.am depended on selected ACL ACL*cc
>> and related
>> sources. These targets depend on acl/* libraries now. As a part of
>> this
>> cleanup, the number of ufsdump sources went from about 160 to about 20.
>> No functionality changes were intended. Source code changes were
>> kept to the
>> minimum. All my build tests are successful. However, since I had to
>> move a lot
>> of files, move some code pieces, and split ACLChecklist, it is
>> possible that
>> some targets will no longer build in some environments and some
>> authentication
>> code will break.
>>
>

This

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)

Clear as mud?

I'll write up a wiki page feature after initial inputs.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE6 or 3.0.STABLE13
   Current Beta Squid 3.1.0.6