httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: Timers and mpm-event
Date Fri, 13 May 2016 14:02:01 GMT
Hijacking this thread...

> Am 13.05.2016 um 15:29 schrieb Eric Covener <>:
> On Fri, May 13, 2016 at 4:33 AM, Luca Toscano <> wrote:
>> - What does PT_USER represents and how it is used?
> PT_USER is what event tracks when you call
> event_register_poll_callback().  This callback
> allows a module to run some code when either of a pair of sockets
> becomes readable or writable.
> It was written to allow mod_proxy_wstunnel to not tie up a thread when
> both ends of the connection
> are idle.
> Note that it is still trunk-only.

Funny that you mention that...

I made a quick and dirty attempt to use this in mod_http2 yesterday. I want to get rid of
the BUSY polling using timeouts that happens when the main connection is waiting for workers
to come back with responses. That can block on a conditional, however it also needs to react
when new data is arriving from the client. So, in its current form, it makes a timed wait
on the conditional and checks the main connection again.

So, I registered on POLLIN on the main connection and signalled the conditional in that callback.
Sort of worked, however was not very stable. Before I put in more work, there are some things
I need to know too. Maybe that helps everyone with understanding this new feature.

1. Is this ever intended to work on a socket that is a main connection? Since event itself
will add this socket to its pollset  now and then, I see a potential conflict. But that can
be resolved, since mod_http2 is only interested in the callback while *inside* process_connection.
If could unregister before returning or whatever is helpful.

2. I assume the callback gets invoked on whatever worker thread is currently available? it
probably should return rather immediately, I assume?

Ideally, however, mod_http2 would use another mechanism:

   a) return from process_connection immediately when there is nothing to do
   b) have outgoing data sitting in output filters for streaming out event based
   c) be called via process_connection again if signaled by someone else*)
      *) someone else would be a slave connection that has produced new data
   d) slave connections could also leave their process_connection and go to "sleep".
      They have no socket, but can be signaled by others that data is available
      or that they can "write" more output.

In this way, slave connections and a master connections are both handled by MPM. While the
latter have a socket that generates POLLIN/OUT/HUP events, the slave ones get these events
generated by something else. This "something else" is in case of HTTP/2 the interworking between
h2 session and stream requests. 

So, in short:
- POLLIN/POLLOUT/HUP event handling can be triggered by other threads via a new MPM API
- Slave connections can be started via a new MPM API. They will not have a socket, but take
part in event handling

That would allow HTTP/2 processing to become fully async and it would no longer need its own
worker thread pool, at least with mpm_event.


View raw message