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: AW: Module: Mod_Dialup (ap_mpm_register_timed_callback)
Date Fri, 25 May 2012 15:54:55 GMT


On 05/25/2012 02:58 AM, Pöchtrager, Bernhard wrote:
>> -----Ursprüngliche Nachricht-----
>> Von: Joe Lewis [mailto:jlewis@silverhawk.net] Im Auftrag von Joe Lewis
>> Gesendet: Donnerstag, 24. Mai 2012 18:06
>> An: modules-dev@httpd.apache.org
>> Cc: Pöchtrager, Bernhard
>> Betreff: Re: Module: Mod_Dialup (ap_mpm_register_timed_callback)
>>
>> 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
> The code of my Handler exits with SUSPENDED. If the Handler doesn't complete the Callback
wouldn't get called.
> Maybe I have to change the state of the handler, but how can I do this? Do you have any
ideas to close the handler?
>
> Here is my actual-Code of the Callback.
> Static void callback(void* data) {
>       request_rec* prr = (request_rec*) data;
>       apr_thread_mutex_lock(prr->invoke_mtx);
>       get_data(prr);		//here I get my data. It's like the handler I used for a synchronous
connection
>       apr_thread_mutex_unlock(prr->invoke_mtx);
>       ap_finalize_request_protocol(prr);
>       ap_process_request_after_handler(prr);
>       prr->status=HTTP_OK;
>       ap_die(DONE, prr);
> }
>
> The handler is:
> static int async_handler(request_rec* prr)
> {
>      ap_mpm_register_timed_callback(apr_time_from_msec(1000),callback,prr);
>      return SUSPENDED;
> }

Question - the mod_dialup.c handler is generating content, but yours is 
not.  How are you generating a response?  Basically, the mod_dialup.c 
handler is sending the contents of a file (including the EOS bucket 
which is supposed to cause the connection to close), and returning 
SUSPENDED, which then triggers in the dialup_callback to either 
re-suspend, or process the request depending on the dialup_send_pulse 
result.

Curiosity - is the previous connection still open when you get to the 
second request that is failing?

Joe


Mime
View raw message