[Patch] nginx to use libatomic_ops

W-Mark Kubacki wmark+nginx at hurrikane.de
Tue Sep 29 14:26:43 MSD 2009

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 [1], 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

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.

W-Mark Kubacki

More information about the nginx mailing list