Hello!

On Thu, Mar 04, 2010 at 10:20:29AM -0500, georgexsh wrote:

> Igor Sysoev Wrote:
> -------------------------------------------------------
>
> > Here is third-party module which probably uses
> > threads:
> >
> > #11 0x08088c9f in ngx_foo_time_str (r=0x9dcdc28,
> > time_str=0xbfe18450, t=-4) at
> > ./ngx_foo_module//uti.c:111
> > #12 0x08087d1a in ngx_http_foo_record
> > (r=0x9dcdc28, request_arg=0x9dcddb0) at
> > ./ngx_foo_module//foo.c:124
> > #13 0x0808788c in ngx_http_foo_handler
> > (r=0x9dcdc28) at
> > ./ngx_foo_module//ngx_http_foo_module.c:74
> >
>
>
> No, ngx_foo_module/* is my module which does't use threads ethier.
>
> ref:
> http://blogs.inxsasia.com/hiran/2009/07/stupid-futex-and-glibc.html
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301511

Ok, second link suggest that recent glibc uses futex even when
there are no threads in application.

This isn't really relevant though as underlying problem is in
nginx and should be fixed anyway. Only async-signal-safe
functions may be used in signal handlers, anything else leads to
undefined behaviour.

For now - use ngx_time() and don't use timer_resolution unless you
have kqueue or eventport.

Maxim Dounin

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx