]> git.ipfire.org Git - thirdparty/haproxy.git/commitdiff
BUG/MEDIUM: stream-int: don't set SI_FL_WAIT_ROOM on CF_READ_DONTWAIT
authorChristopher Faulet <cfaulet@haproxy.com>
Mon, 22 Oct 2018 19:34:21 +0000 (21:34 +0200)
committerWilly Tarreau <w@1wt.eu>
Tue, 23 Oct 2018 08:22:36 +0000 (10:22 +0200)
With the previous connection model, when we purposely decided to stop
receiving in order to avoid polling after a complete request was received
for example, it was needed to set SI_FL_WAIT_ROOM to prevent receive
polling from being re-armed. Now with the new subscription-based model
there is no such thing anymore and there is noone to remove this flag
either. Thus if a request takes more than one packet to come in or
spans over too many packets, this flag will cause it to wait forever.
Let's simply remove this flag now.

This patch should not be backported since older versions still need
that this flag is set here to stop receiving.

src/stream_interface.c

index 04eedf2be823a2fcb9e4305192953b9af741b72b..59827ecadc476ecbf2f8fd6347499a9632f484de 100644 (file)
@@ -1207,15 +1207,8 @@ int si_cs_recv(struct conn_stream *cs)
                        break;
                }
 
-               if ((ic->flags & CF_READ_DONTWAIT) || --read_poll <= 0) {
-                       /*
-                        * This used to be __conn_xprt_done_recv()
-                        * This was changed to accomodate with the mux code,
-                        * but we may have lost a worthwhile optimization.
-                        */
-                       si->flags |= SI_FL_WAIT_ROOM;
+               if ((ic->flags & CF_READ_DONTWAIT) || --read_poll <= 0)
                        break;
-               }
 
                /* if too many bytes were missing from last read, it means that
                 * it's pointless trying to read again because the system does