Hi Stefan,

thanks for the answers! Commenting inline:

2016-02-01 10:54 GMT+01:00 Stefan Eissing <stefan.eiss...@greenbytes.de>:
>
>
> > - mod_ssl and mod_deflate are examples of filters that needs to act on
> the whole response so a worker gets stuck flushing data to slow clients
> rather than giving up the socket earlier to the listener and doing a
> different work.
>
> Hmm, not sure I understand your point. Every part in the process of
> generating the bytes sent out on the socket is involved here. The crucial
> difference between the worker and the event mpm is:
> - worker keeps the response state on the stack
> - event keeps the response state in the heap
> which means that calls to response processing
> - on worker, need to return when all is done
> - on event, may return whenever a READ/WRITE event or TIMEOUT/KEEPALIVE is
> needed.
>
> In that way, writing a response with event is "stutter stepping" it. Write
> until EWOULDBLOCK, return, queued, event, write until EWOULDBLOCK,...
>
> (my understanding)
>

Really sorry for my poor explanation, but I am still in early phases when
you bang your head against httpd's code until you get something out of it :)

More context from the doc:

"A similar restriction is currently present for requests involving an
output filter that needs to read and/or modify the whole response body,
like for example mod_ssl, mod_deflate, or mod_include. If the connection to
the client blocks while the filter is processing the data, and the amount
of data produced by the filter is too big to be buffered in memory, the
thread used for the request is not freed while httpd waits until the
pending data is sent to the client."

After a chat in #httpd-dev I realised that this use case is not the
standard one for processing a https connection with event, but only a
corner case. For some reason this lead me to think that event was handling
HTTPS connections like worker in all the use cases (some sysadmin friends
thought the same too). It might be necessary only to add this note and
everything would be clearer in my opinion.

My goal is to reduce the time to understand mod-event (and to appreciate
all its greatness) for the "standard guy" like me. I now realise that the
docs are containing all the info that I needed but for some reason I wasn't
getting the correct picture out of it (some processing errors in my brain
might also be part of the problem but I can't easily fix it :)

Thanks! Looking forward to have other feedbacks!

Luca

Reply via email to