18.11.2019 18:11, Maxim Dounin wrote:
> Hello!
>
> On Mon, Nov 18, 2019 at 05:48:46PM +0100, Sergey Brester wrote:
>
>> Looks like [efd71d49bde0 [2]] could be indeed responsible for that: I see at
>> least one state where rev->ready could remain 1 (after rev->available gets
>> 0) e. g. deviation between blocks [efd71d49bde0#l10.8 [3]] and
>> [efd71d49bde0#l11.8 [4]] where first did not reset rev->ready and for
>> example if ngx_socket_nread in [efd71d49bde0#l10.38 [5]] would write 0 into
>> rev->available, so rev->ready remains 1 yet.
>
> There is no deviation here. The rev->available field holds the
> number of bytes available for reading (or -1 if it's not known),
> while rev->ready indicates if reading is possible. The reading
> can be possible even WHEN REV->AVAILABLE IS ZERO - notably, when
> there is a potential pending EOF.
Sure,
but I told about the case where rev->ready indicates the READING IS
POSSIBLE,
but REV->AVAILABLE IS LESS AS ZERO.
If you mean this is to noglect, then it is ok, but somehow it looks
backwards incompatible to me.
At least other async-IO procedures (for example KQUEUE [1]) handle this
differently.
Anyway I saw never REV->AVAILABLE LESS AS ZERO, if rev->ready got 1
until now.
Regards,
Sergey.
Links:
------
[1]
https://github.com/nginx/nginx/commit/fac4c7bdf53ee7d8fec6568f1e9fecefcde6feba#diff-0b707fd972a54f561081982c62457febR155-R158
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
