All files from this thread

File Name	File Size		Posted by	Date
nginx-0.8.16-libatomic.patch	3.9 KB	open | download	W-Mark Kubacki	10/09/2009	Read message

2009/9/29 Igor Sysoev <is@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
ngx_atomic.h.

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
http://mark.ossdl.de/