On 9/3/21 1:01 PM, Yann Ylavic wrote:
> On Tue, Aug 31, 2021 at 9:29 AM Ruediger Pluem <rpl...@apache.org> wrote:
>>
>> On 8/30/21 8:04 PM, yla...@apache.org wrote:
>>>
>>> +            /* We want to write if we asked for POLLOUT and got:
>>> +             * - POLLOUT: the socket is ready for write;
>>> +             * - !POLLIN: the socket is in error state (POLLERR) so we let
>>> +             *   the user know by failing the write and log, OR the socket
>>> +             *   is shutdown for read already (POLLHUP) so we have to
>>> +             *   shutdown for write.
>>>               */
>>>              if ((tc->pfd->reqevents & APR_POLLOUT)
>>>                      && ((pfd->rtnevents & APR_POLLOUT)
>>> +                        || !(tc->pfd->reqevents & APR_POLLIN)
>>
>> Why should we write if we requested POLLOUT did not get POLLOUT back, but 
>> did not request for POLLIN?
> 
> What I want to avoid in this loop is to handle all the POLLIN|POLLERR
> or POLLOUT|POLLERR or POLLERR alone which depend on the system.
> So it's written such that there is no "blank" pass, when no
> POLLIN|POLLHUP or POLLOUT is returned (likely an error condition) we
> will issue either a read or a write (in that order of preference) to
> catch the error at the core filters' level.
> This was missing the POLLOUT|POLLHUP case when the socket is shutdown
> for read already, meaning that we will never get POLLIN anymore, and
> this is fixed by this !(reqevents & APR_POLLIN) case to issue a write
> (well a shutdown for write exactly here) when no read is to be issued
> below.
> 
> Does it make sense?

Just to be sure. We need this because

1. We requested POLLOUT
2. We did not get POLLOUT back, but rtnevents might contain POLLHUP and or 
POLLIN and hence the last condition existing before the
patch (!(pfd->rtnevents & (APR_POLLIN | APR_POLLHUP))) would not trigger. The 
new condition ensures in these cases that we flush
stuff even if blocking and close down write.

This means we could also use

tc->other->down_in == 1

instead of !(tc->pfd->reqevents & APR_POLLIN)

to get the same results?

Or does it need to be !(tc->other->pfd->reqevents & APR_POLLIN) instead of 
!(tc->pfd->reqevents & APR_POLLIN) ?

Still confused.

Regards

RĂ¼diger

Reply via email to