BUG/MEDIUM: stream-int: always set SI_FL_WAIT_ROOM on CS_FL_RCV_MORE
When a stream interface tries to read data from a mux using rcv_buf(), sometimes it sees 0 as the return value and concludes that there's no more data while there are, resulting in the connection being polled for more data and no new attempt being made at reading these pending data. Now it will automatically check for flag CS_FL_RCV_MORE to know if the mux really did not have anything available or was not able to provide these data by lack of room in the destination buffer, and will set SI_FL_WAIT_ROOM accordingly. This will ensure that once current data lying in the buffer are forwarded to the other side, reading chk_rcv() will be called to re-enable reading. It's important to note that in practice it will rely on the mux's update_poll() function to re-enable reading and that where the calls are placed in the stream interface, it's not possible to perform a new synchronous rcv_buf() call. Thus a corner case remains where the mux cannot receive due to a full buffer or any similar condition, but needs to be able to wake itself up to deliver pending data. This is a limitation of the current connection/conn_stream API which will likely need a new event subscription to at least call ->wake() asynchronously (eg: mux->{kick,restart,touch,update} ?). For now the affected mux (h2 only) will have to take care of the extra logic to carefully enable polling to restart processing incoming data. This patch relies on previous one (MINOR: conn_stream: add new flag CS_FL_RCV_MORE to indicate pending data) and both must be backported to 1.8.
This commit is contained in:
parent
3c8294b607
commit
6577b48613
@ -1185,6 +1185,9 @@ static void si_cs_recv_cb(struct conn_stream *cs)
|
||||
}
|
||||
|
||||
ret = conn->mux->rcv_buf(cs, ic->buf, max);
|
||||
if (cs->flags & CS_FL_RCV_MORE)
|
||||
si->flags |= SI_FL_WAIT_ROOM;
|
||||
|
||||
if (ret <= 0)
|
||||
break;
|
||||
|
||||
|
Loading…
x
Reference in New Issue
Block a user