httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Bligh <a...@alex.org.uk>
Subject Re: Mutex protection of output bucket brigade
Date Wed, 12 Jun 2013 09:48:54 GMT

On 12 Jun 2013, at 10:20, Sorin Manolache wrote:

> If I understand correctly, the main thread belongs to your module, i.e. it is not a concise
pseudo-code of the request processing in apache's code.

The main thread is the (presumably single) thread of the prefork mpm process, created (I assume)
by a fork() in apache's worker code.

The pseudo code was what my long-running request handler does (after creating the other thread).
IE, broadly speaking my request handler (the main thread if you like) does this:

 apr_thread_create; /* create the spawned thread */
 while (!done)
  {
    /* Blocking read */
    apr_brigade_create;
    ap_get_brigade;
    apr_brigade_flatten;

    /* Do stuff with the data */
    blocking_socket_write;
  }
 apr_thread_join; /* wait until the spawned thread has executed */

> I don't see where the output brigade appears in the main thread. I think this is critical,
as the output_bucket_brigade is the data item shared between the two threads. ap_get_brigade
triggers the execution of the chain of input filters. One of these input filters writes to
the output brigade?

ap_get_brigade is called with APR_BLOCK_READ.

What I now /believe/ this does (because it's the only way data would actually get written)
is write the post processed output bucket brigade to the client too. If this were not the
case, it's difficult to see how a single threaded application would every write the output
bucket brigade.

Or are you saying the output bucket brigade is only actually written to the client during
an ap_fwrite()? In which case are all the filters (primarily mod_ssl) guaranteed to be thread
safe if a different thread is doing input from that doing output?

-- 
Alex Bligh





Mime
View raw message