m4ssi has quit [Remote host closed the connection]
<sb0>
whitequark: is it really harder to implement the missing 3.7 features than switch to redbaron?
<sb0>
whitequark: in smoltcp, is it correct that the peek() function on TCP sockets returns a buffer that is truncated at the internal ring-buffer boundary? and that buffer can be shorter than what is returned by recv_queue()?
<sb0>
whitequark: if so, this should be documented, and also, what about a way to get a second buffer after the ring-buffer boundary?
<sb0>
whitequark: and btw the py3.7 features aren't really a big issue in practice, but compilation speed is
jevinskie has joined #m-labs
ohsix has joined #m-labs
ohsix has quit [Ping timeout: 248 seconds]
ohsix has joined #m-labs
proteusguy has quit [Remote host closed the connection]
<whitequark>
"Call f with the largest contiguous slice of octets in the receive buffer, and dequeue the amount of elements returned by f."
<sb0>
well ok, but it should be more explicit
<sb0>
e.g. add to recv_queue() that the value returned is different from the size of the largest contiguous slice
<whitequark>
yeah, adding that now
<sb0>
also, "largest contiguous slice" is a bit unclear. if you have 1 byte, then the ring buffer wraps around, then 100 bytes, the "largest contiguous" slice is the 100-byte one
<whitequark>
well TCP guarantees in-order delivery
<sb0>
would it make sense to return a "ring buffer contents" object instead, which contains up to two slices, lets you access them, and also has convenience methods such as index and iterator support?
<sb0>
you could say "largest contiguous slice starting at the first received byte in the buffer"
<whitequark>
sure, but there's no other way it can possibly work...
<travis-ci>
m-labs/smoltcp#1287 (master - 4cec6ee : whitequark): The build was broken.
<whitequark>
rjo: I'd be interested to see what kind of zero copy use case you have in mind
<whitequark>
here's why:
<whitequark>
if you already have a slice handy (which is larger than the contiguous slice in the socket buffer), then you can call send_slice or recv_slice twice
<whitequark>
this has very little overhead
<whitequark>
if you *don't* have a slice handy, then each write into the ring buffer (or the representation of the ring buffer as two concatenated &mut slices) will have to do a length check, and if the write is truncated after all, you have to suspend it somehow
<whitequark>
so it doesn't look like adding one more API would help much here anyway
<whitequark>
now, maybe I'm wrong, but I don't see where
<sb0>
whitequark: but then recv_slice copies the data into the slice you provided
<whitequark>
sb0: sorry, I was unclear
<whitequark>
if you have a slice handy, you can call recv twice
<whitequark>
or let's even consider a different case
<whitequark>
suppose you *never* want to copy data *anywhere*. you want to do everything right in the TCP socket buffer.
<whitequark>
since it is legal for the peer to drip the data to you one byte at a time, correctness requires that you be able to restart after every single byte
<whitequark>
that means that however you are handling the data (without copies that is), you can always just call recv twice and provide the same callback
<whitequark>
does this make sense?
<sb0>
there's one case that isn't covered: if you can parse the request (and remove it from the buffer) only after it becomes a full request, and you use the socket buffer in the meantimg
<sb0>
*meantime
<whitequark>
use how?
<sb0>
to store the partial request
<whitequark>
actually, nevermind, I think I see the issue
<whitequark>
it's an issue specific to peek()
_whitelogger has joined #m-labs
<_whitenotifier-3>
[m-labs/smoltcp] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/fjwWA
<_whitenotifier-3>
[m-labs/smoltcp] whitequark da1f2a8 - Fix docstrings for TcpSocket::{send,recv}_slice(). NFC.
<_whitenotifier-3>
[m-labs/smoltcp] whitequark 30e7bab - Fix docstring for SocketRef::into_inner(). NFC.
<rjo>
whitequark: yes. this seemed specific to peek. once i can have a peek() to all of the buffered data i can decide whether it contains a frame of data.
<rjo>
whitequark: the io Traits would also be really good in many cases. if that can be done reasonably easily.
<rjo>
whitequark: the other thing that i am eager to see (but i don't feel qualified to implement it) is a real-world no_std example of doing the iface::poll() stuff in the MAC DMA interrupt handler (i.e. do minimal work to handle transfer between the DMA buffers and the socket buffers so that DMA gets free descriptors as early as possible) and the rest in other context (whatever the event loop/task model is).
rohitksingh has quit [Ping timeout: 272 seconds]
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined #m-labs
proteusguy has quit [Remote host closed the connection]
proteusguy has joined #m-labs
cr1901_modern1 has joined #m-labs
cr1901_modern has quit [Ping timeout: 258 seconds]
rohitksingh has joined #m-labs
cr1901_modern1 has quit [Quit: Leaving.]
cr1901_modern has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
rohitksingh has joined #m-labs
balrog has joined #m-labs
rohitksingh has quit [Ping timeout: 250 seconds]
cr1901_modern has quit [Ping timeout: 246 seconds]