httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Lewis <...@joe-lewis.com>
Subject Re: Module: Mod_Dialup (ap_mpm_register_timed_callback)
Date Thu, 24 May 2012 16:06:08 GMT
On 05/24/2012 03:26 AM, Pöchtrager, Bernhard wrote:
>
> I created two files. One file with a strace of a successful request and one with a strace
of an unsuccessful request.
> The first significant differences between these two requests are following lines.
>
> 4171<... futex resumed>  )             = -1 EAGAIN (Resource temporarily unavailable)
> 4170<... futex resumed>  )             = -1 EAGAIN (Resource temporarily unavailable)
> 4169<... futex resumed>  )             = -1 EAGAIN (Resource temporarily unavailable)
> 4168<... futex resumed>  )             = -1 EAGAIN (Resource temporarily unavailable)
> 4167<... futex resumed>  )             = -1 EAGAIN (Resource temporarily unavailable)
> 4166<... futex resumed>  )             = -1 EAGAIN (Resource temporarily unavailable)
> 4164<... futex resumed>  )             = -1 EAGAIN (Resource temporarily unavailable)
> 4171  futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
> 4170  futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
> 4169  futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
> 4168  futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
> 4167  futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
> 4166  futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
> 4164  futex(0x1eda654, FUTEX_WAIT_PRIVATE, 42, NULL<unfinished ...>
>
> Well I think that the first request didn't finish correctly. But what can I do?
> Do you have any ideas?
>
> Bernhard

"futex", based on "mutexes", are locking mechanisms and are used to 
prevent work from being done while something else is working (e.g. on 
data to prevent corruption).  I am unfamiliar with 
ap_mpm_register_timed_callback, so I pulled up the apache source to see 
what it is doing.  Apparently, the source has a comment in 
include/httpd.h about it :

/** Mutex protect callbacks registered with ap_mpm_register_timed_callback
      * from being run before the original handler finishes running
      */

Looking at the trace and seeing the comment indicates that the original 
handler has not completed.  In fact, if you look at the source file 
modules/test/mod_dialup.c, it has an example but it uses the 
apr_thread_mutex_lock and apr_thread_mutex_unlock functions in the call 
back that is registered, and it re-registers the call back if it needs 
to check again (e.g. if it still has data to send back to the client), 
but it still unlocks the mutex.

Have you checked to ensure your handler has exited?

Joe

Mime
View raw message