Re: [RFC] SMP dependency hell

On 02/03/2011 11:38 PM, Amos Jeffries wrote:

> I think the moving the Coordinator to a registry subscription pattern is
> what we need to do to fix the depdendency hell from SNMP support changes
> yesterday.
>
> The problem stems around src/ipc/Coordinator.* containing
> handle*Request() handle*Response() for particular components which are
> it's users. The obvious ones are Snmp req/resp but the cachemgr ones
> also hit from the inverse side.
>
> In the end the SNMP and MGR components should be higher level than IPC
> and register a Subscription handler/call with it for runtime selection
> instead of being hard coded at build time.

I agree that a subscription mechanism is a better design here and would
reduce the number of inter-dependencies.

Moreover, Coordinator and Strand classes do not really belong to ipc/.
They have the same "level" as general "worker" code. We may not have a
good place to put Coordinator right now, but the ipc library is not it.

Should we move Coordinator into src/? Create a dedicated src/coord
directory for it? Any better ideas?

What about Strand (the thing that handles IPC messages for workers)?
Create a src/worker directory/library for it?!

I have not seen the actual problems yet (behind on squid-dev email), but
it sounds like there are problems with building test cases and such,
discovered, as always, after commit. The subscription API will not
necessarily fix all of these for the reasons described by Christos, but
it may ease the pain of figuring out the right magical combination of
libraries in src/Makefile.am by reducing the number of dependencies.
Moving Coordinator outside ipc will also help.

If needed, I can help with the subscription design after SMP Rock Store
is merged.

HTH,

Alex.
Received on Tue Feb 15 2011 - 05:39:13 MST