[ANNOUNCE] Tengine-1.4.0

Joshua Zhu zhuzhaoyuan at gmail.com
Tue Sep 11 04:16:55 UTC 2012

Hi Maxim,

On Fri, Sep 7, 2012 at 4:47 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> Hello!
> On Fri, Sep 07, 2012 at 10:07:08AM +0800, Joshua Zhu wrote:
>> Hi Michael,
>> On Fri, Sep 7, 2012 at 12:27 AM, Michael Shadle <mike503 at gmail.com> wrote:
>> > Maxim,
>> >
>> > I knew the ABI reasoning was behind it as this has came up at least once before. Just wanted to express it again. Curious how tengine does it with very small performance loss still based off the nginx code base. Perhaps something to look at? :) that's all.
>> >
>> We already know the limitations pointed out by Maxim and thank Maxim
>> for making it clear several times. Definitely it's difficult to solve
>> them, especially the ABI problem. The approach we'll take is keeping
>> the ABI of the stable versions as conservative as we can, i.e. we'll
>> not change the ABI of a stable branch. And the ABI changes will just
>> happen in a development branch.
>> In such a way it may reduce the value of dynamically loaded modules,
>> but it's better than nothing.
> The question isn't really about "keeping ABI in the stable
> branch", checking version signature is more or less enough here
> (unless you apply patches which change the ABI within the same
> version).
> It's more about what happens once you'll try to load a module
> compiled with --with-ipv6 into nginx compiled without this flag
> (or vice versa).  Layout of the ngx_connection_t structure will be
> different in nginx itself and the module, and the resulting code
> will happily do various unexpected thing.

Thank you very much for your valuable comments :)

I think there should be solutions, though it's difficult to fix the
conditional compilation problem. For example, we can use the same
configure options (--with-ipv6, and etc) when compiling a dynamically
loaded module. And nginx must be recompiled once such a configure
option is changed. For a module which introduces conditional
compilations, we can make it compiled in forcibly if the DSO feature
is enabled. Plus, IMHO, some conditional compilations are not
necessary hence could be removed.

> And the same thing may even happen without any changes in
> configure arguments - e.g. if OS was upgraded and nginx
> now detects some new feature it want to use.

It's not a problem caused by dynamically loaded modules. It exists
even in statically compiled nginx. The accept4() problem (yeah it has
been fixed) is an example :)


Joshua Zhu
Senior Software Engineer
Server Platforms Team at Taobao

More information about the nginx mailing list