BUG/MEDIUM: stconn: Report a blocked send if some output data are not consumed
Instead of reporting a blocked send if nothing is send, we do it if some
output data remain blocked after a write attempts or after a call the the
applet's I/O handler. It is mandatory to properly handle write timeouts.
Indeed, if an endpoint is blocked for a while but it partially consumed
output data, no timeout is triggered. It is especially true for
connections. But the same may happen for applet, there is no reason.
Of course, if the endpoint decides to partially consume output data because
it must wait to move on for any reason, it should use the se/applet API
(se/applet_will_consume(), se/applet_wont_consume() and
se/applet_need_more_data()).
This bug was introduced during the channels timeouts refactoring. No
backport is needed.
diff --git a/src/stconn.c b/src/stconn.c
index 3c19cfc..39299b1 100644
--- a/src/stconn.c
+++ b/src/stconn.c
@@ -1667,12 +1667,8 @@
oc->flags |= CF_WRITE_EVENT | CF_WROTE_DATA;
if (sc->state == SC_ST_CON)
sc->state = SC_ST_RDY;
-
sc_have_room(sc_opposite(sc));
- sc_ep_report_send_activity(sc);
}
- else
- sc_ep_report_blocked_send(sc);
if (sc_ep_test(sc, SE_FL_ERROR | SE_FL_ERR_PENDING)) {
oc->flags |= CF_WRITE_EVENT;
@@ -1681,9 +1677,14 @@
return 1;
}
- /* We couldn't send all of our data, let the mux know we'd like to send more */
- if (!channel_is_empty(oc))
+ if (channel_is_empty(oc))
+ sc_ep_report_send_activity(sc);
+ else {
+ /* We couldn't send all of our data, let the mux know we'd like to send more */
conn->mux->subscribe(sc, SUB_RETRY_SEND, &sc->wait_event);
+ sc_ep_report_blocked_send(sc);
+ }
+
return did_send;
}