httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject buckets across threads - question
Date Tue, 17 Mar 2015 15:59:43 GMT
Hi,

I have a question regarding my http2 module implementation, where I seem to fail to wrap my
head around the limitations of pools and bucket brigades in a multi-threaded environment.
As I understand it, httpd has - so far - the underlying assumption:

 1 connection -> 1 request -> 1 thread

at a single point in time. This used to be quite static, as in mpm_worker, and was made more
dynamic with mpm_event, which may switch the thread around. However even though entities might
be exchanged, it is always 1-1-1 at a single point in time.

Now, as most of you are aware, with the HTTP/2 processing model, this holds no longer true.
The relation there is 1-m-m* and, worse, the connection is multiplexing requests, so there
are many active at the same time and their data will be interleaved. The request/thread coupling
can stay as it is, but the connection relation is different.

I today have a working implementation and it has major drawbacks (among all the bugs I need
to find):

1. it mimicks httpd objects that are not really there, e.g. pseudo-connections, so that there
seems to be a 1-1 with connections and requests again (just as mod_spdy does). Therefore it
needs to fake HTTP/1.1 requests, so that core filter can parse them, etc.

2. beautiful apr infrastructure like bucket brigades are not used when data needs to be passed
between threads.

I have made an attempt today to make bucket brigades work for passing data between threads,
but things keep crashing on me when load grows. Which is all my fault for not understanding
these things fully. So, am I on a fool's errand? Can I have brigade A in thread 1 and brigade
B in thread 2 and pass buckets between them without excessive copying? I think I am doing
it wrong and the cleanups of the allocators run in the wrong thread in the end which is not
healthy.

As for the request processing, I saw that there is a ap_process_request(r) to be had. Is it
worthwhile to see if that can be called directly without ap_read_request() creating it. That
would eliminated at least the request->HTTP/1 serialization...

Any ideas or hints appreciated.


//Stefan


<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782




Mime
View raw message