Re: [PATCH] libecap v1.0 support

On 10/31/2013 03:20 AM, Amos Jeffries wrote:

> As I understand library design the library version N should be offering
> the same ABI symbols from library N-1 and as far back N-x as possible.

Correct. The problem here is not offering the same symbols, but offering
the same class definitions (or same virtual tables, to be precise).
Unfortunately, in this case, x is zero. Libecap v1.0 does not offer the
exact same set of virtual methods in some classes so it is not binary
compatible with libecap v0.2.

For a background on this subject, see
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++

> I am checking whether the library 1.0/1.1 versions are supported like
> this because most of our downstream distributions will need to release
> packages of newer libecap library before releasing version of Squid with
> these changes. Having a forced in-sync step between the library and
> proxy will cause transition problems for them. If we can make Squid
> still build and/or run against the older libraries it would be helpful
> avoiding problems there.

Agreed, but I do not think we can. Libecap v1.0 adds virtual functions
to a few key classes, which makes those classes binary incompatible with
libecap v0.2.

We could have designed these libecap changes differently, but after
careful consideration and experimentation, we have decided that the
complexity and performance overheads of the alternative designs are not
worth it.

Yes, folks will need to install newer libecap if they want to use newer
Squids with eCAP. This is the price they have to pay for using a new,
evolving library. Moreover, I expect at least one more such
incompatible change in the foreseeable future because libecap does not
have all the features it needs yet (IMO). I wish the upgrade would be
smoother, but I do not think this is such a big deal in practice.

>> Please keep in mind that there can be are up to 2+N libecap versions
>> that Squid needs to deal with, where N is the number of eCAP adapters:
>>
>> (1) libecap Squid was built with
>> +
>> (1) libecap Squid is running with
>> +
>> (N) libecap adapters were built with.
>>
>> It is possible to configure "Squid built with libecap v1.0" to load an
>> "adapter built with libecap v0.2". I ran many tests like that. Old
>> Squids would crash and burn in similar version mismatch cases. With this
>> patch, Squid warns the admin about the adapter version mismatch and
>> either exits or runs OK, depending on squid.conf IIRC (but Squid may
>> still crash and burn on exit when global library destructors are called
>> -- nothing we can do about that AFAIK).
>
> Okay. So Squid configured in such a way that the library calls only use
> 0.2 API symbols still works. Good.

Overall, Squid works (except for the exit problems). The old eCAP
adapter does not (and possibly cannot).

> What then is blocking Squid from supporting build against either 0.2 or
> 1.0 library version?
> We have feature-detection possible in configure.ac and #if macros to
> build in/out support code based on those results.

I do not think it is a good idea to support both library versions in the
same Squid code base. The complexity is not worth it IMO.

> It sounds to me like
> the library gobal destructors need to be better protected internally
> from crashing, but that is an ecap problem.

I do not have a complete understanding of those crashes, but I suspect
they are not libecap or Squid fault. They seem to stem from internal
at-exit cleanup code generated by GCC and outside of libecap or Squid
control. I suspect that the generated code steps on its own feet when
two similar but different libraries are cleaning up. It is very similar
to an executable with two standard C++ library versions inside. It is
unlikely to work well.

> The important thing is that if we apply this today our releases of Squid
> will still need to build on systems only supplying libecap 0.2.

Squid can still be built on those systems, but it will not support eCap
until those systems are upgraded to libecap v1.0.

> Its not a blocker, but if you could find a way to allow build against
> those old library versions as well as the new ones it would be helpful.

I do not think the short-term benefits of such compatibility are worth
the short- and long-term costs of providing it. The issues are far more
complex than #ifdefing a couple of calls.

Thank you,

Alex.
Received on Thu Oct 31 2013 - 15:19:47 MDT