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
