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

Hello!

On Fri, Oct 09, 2009 at 11:57:24AM +0200, W-Mark Kubacki wrote:

> 2009/10/8 Igor Sysoev <is@rambler-co.ru>:
> > On Tue, Sep 29, 2009 at 12:26:43PM +0200, W-Mark Kubacki wrote:
> >
> >> [...]
> >> 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.
>
> On x86/amd64 the shipped assembler code works fine, and my libatomic
> patch was intended for 'other' architectures.
> Despite of the latter I believe reinventing the wheel (as did php-fpm)
> is no good engineering - and you need to maintain that code yourself
> rather than have the 'community' do that for you (and other projects).
>
> Unfortunately I don't know the "complex" libraries good enough to tell
> whether they contain atomic ops nor whether they export it.

The idea is that for simple and rarely changing things like atomic
ops it's better to have them in-place instead of in external
library. As external library may change, broke, disappear and so
on, as a result requiring much more attention then simple in-place
code.

Note well: I believe the actual problem isn't atomic ops that
isn't here. By design nginx should work without atomic ops. The
real problem is SIGSEGV you see without them. It should be fixed,
but unfortunately we have no hardware to reproduce the problem.

Maxim Dounin