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

On Tue, Sep 29, 2009 at 12:26:43PM +0200, W-Mark Kubacki wrote:

> 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.

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.


--
Igor Sysoev
http://sysoev.ru/en/