Yes. There's also the unfortunate collision with io.ReaderFrom's method name which is directionally opposite to net.PacketConn's ReadFrom. This is unfixable because of Go1.
Dan On Mon, 2019-05-13 at 15:14 -0700, Ian Lance Taylor wrote: > On Mon, May 13, 2019 at 2:45 PM Dan Kortschak <d...@kortschak.io> > wrote: > > > > > > Thanks, Jake. This was very helpful. > It does seem that the docs in this area should be improved. Alas. > > Ian > > > > > > On Mon, 2019-05-13 at 09:19 -0700, jake6...@gmail.com wrote: > > > > > > On Thursday, May 9, 2019 at 2:54:17 AM UTC-4, kortschak wrote: > > > > > > > > > > > > > > > > The Conn and UDPConn Read methods look like io.Reader Read > > > > methods, > > > > but > > > > there is no explicit claim that Conn is an io.Reader. Are the > > > > Read > > > > methods of these two types identical in behaviour to io.Reader? > > > > > > > I can not say definitively, but on unix, UDPConn.Read() is > > > actually > > > net.conn.Read() <https://golang.org/src/net/net.go?s=6157:6199#L1 > > > 63>, > > > whch > > > calls net.netFD.Read(), which in turn calls poll.FD.Read() > > > <https://golang.org/src/internal/poll/fd_unix.go#L144>. You can > > > see > > > there > > > in the code: > > > > > > // Read implements io.Reader. > > > > > > The windows and plan9 versions also land in Read() functions that > > > have the same comment. So it seems to me that UDPConn.Read() is > > > an > > > io.Reader. Of course, that only means that it conforms to the > > > requirements of io.Reader <https://golang.org/pkg/io/#Reader>. > > > > > > Specifically, are the reads allowed to fill the buffer with > > > arbitrary > > > > > > > > > > > > numbers of bytes in 0 <= len(p) <= n? > > > > > > > Yes, according to io.Reader <https://golang.org/pkg/io/#Reader> > > > docs, > > > an > > > implementation may do that. Looking at the actual implementations > > > of > > > the > > > poll.FD.Read functions, I would say that it seems like they will > > > always > > > return the full UDP packts, if it is <= len(p). A full search of > > > the > > > relevant platform docs would be required to say definitively. > > > > > > > > > > > > > > > > > > Also, can UPDConn.Read fill the buffer with more than one > > > > packet if > > > > the > > > > buffer would accommodate that? (I am guessing yes, and that if > > > > this > > > > is > > > > important then the ReadFrom method should be used). > > > > > > > > > > > It looks to me like this will in fact read one packet at a time > > > on > > > amd64 > > > unix. The function will return after a single successful > > > syscall(SYS_READ) > > > which, IIUC will just be one packet for UDP. Since there is no > > > actual > > > documentation guaranteeing this, you would have to look at the > > > source > > > code, > > > and platform docs, for every platform you care about to be 100% > > > sure. > > > However, if it did not work this way, it would make UDP > > > programming > > > very > > > hard, or even impossible. So I think it very likely. > > > > > > > > > > > > > > > > > > thanks > > > > Dan > > > > > > > > > > > > -- > > You received this message because you are subscribed to the Google > > Groups "golang-nuts" group. > > To unsubscribe from this group and stop receiving emails from it, > > send an email to golang-nuts+unsubscr...@googlegroups.com. > > To view this discussion on the web visit https://groups.google.com/ > > d/msgid/golang-nuts/1557783886.17937.0.camel%40kortschak.io. > > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1557791271.21310.94.camel%40kortschak.io. For more options, visit https://groups.google.com/d/optout.
