Hijacking this thread...
> Am 13.05.2016 um 15:29 schrieb Eric Covener <[email protected]>:
>
> On Fri, May 13, 2016 at 4:33 AM, Luca Toscano <[email protected]> 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.
Thoughts?
-Stefan
