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