You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Allow TCPConnectionNotify to cause connection to yield while receiving (ponylang#1355)
This comes from direct experience using the existing `TCPConnection`
functionality at Sendence. We are heavy users of `expect` on `TCPConnection` in
order to support framed protocols. Our `received` methods on notifiers are
generally of the following form:
```pony
fun ref received(conn: TCPConnection ref, data: Array[U8] iso) =>
if _header then
// convert the 4 byte header into a value for expect, aka payload length
let expect = Bytes.to_u32(data(0), data(1), data(2), data(3)).usize()
conn.expect(expect)
_header = false
else
// do something with payload
...
// reset expect for next 4 byte header
conn.expect(4)
_header = true
end
```
This short of usage is why `expect` was initially added to `TCPConnection`.
Upon usage, we found a serious drawback with this approach. `TCPConnection`
will read up to 4k of data on a single behavior run and if there is still data
available, it will then send itself a `_read_again` message to trigger more
reading of additional data. It does this so that it doesn't hogged the
scheduler while reading from the socket. This can work reasonably well in some
scenarios but not others.
In the framed protocol example above, if the message payloads are small then
4k of data can result in a lot of messages being sent from our `received`
method to other actors in the application. In an application that is
continously receiving data, this results in a very bursty scheduling experience.
After consulting with Sylvan, we changed `received` and `TCPConnection` to
allow `received` to return a Boolean to indicate whether `TCPConnection`
should continue sending more data on this behavior run.
We've found that for some workloads, we are able to get equal performance
while greatly lowering latency by having `TCPConnection` call `_read_again`
earlier than it otherwise would.
Closes RFC ponylang#19Closesponylang#1343
0 commit comments