[Patch] nginx to use libatomic_ops
is at rambler-co.ru
Thu Oct 8 19:47:01 MSD 2009
On Tue, Sep 29, 2009 at 12:26:43PM +0200, W-Mark Kubacki wrote:
> 2009/9/29 Igor Sysoev <is at rambler-co.ru>:
> > On Fri, Sep 25, 2009 at 09:46:33PM +0200, W-Mark Kubacki wrote:
> >> I have experienced SEGFAULTs on ARM using fastcgi and discovered it
> >> compiles with "NGX_HAVE_ATOMIC_OPS 0" on 'other' architectures than
> >> x86, amd64, sparc and the such defined in src/os/unix/ngx_atomic.h.
> >> Therefore I'd like to contribute the patch linked below , which
> >> introduces configure option "--with-libatomic" [...]
> > Thank you for the patch and information about gcc 4.1.
> > I'm going to add gcc builtins, since they are slighty lesser than
> > my code at least on x86.
> > I'm not sure should libatomic be added, since gcc 4.1+ is common compiler
> > these days.
> > Could you show backtrace of the segfault ? I could not reproduce it
> > on x86 with disabled atomic ops.
> The segfaults happened on ARM architecture, not x86.
> Eliminating lock_file by introducing atomic ops the only code which
> got not called after that were the emulations at the bottom of
I understand that segfaults was happened on ARM. However, I tried
to reproduce them on x86 with disabled atomic operations.
> GCC builtins work for me, too, but they make nginx be linked against a
> specific libgcc (that of the particular GCC version) and yield more
> overhead (2kb libatomic_ops w/o any link vs. 13kb GCC builtins).
> Finally libatomic_ops can be compiled by other means (such as MSVC,
> ICC, SUNC for example) therefore I prefer them for portability.
> What do you think about the compromise using GCC builtins if
> --with-libatomic is not set?
> Only architectures not covered by the #ifs would be affected and you
> could remove lock_file code entirely in future.
On i386/amd64 gcc builtins are just inlines and do not require libgcc.
As to libatomic, I'm not sure now. I prefer to use complex libraries
such as OpenSSL, zlib, etc.
More information about the nginx