Thank you. I have reviewed the code. I was hoping for some friendly and
helpful input.
On Sun, 2019-05-12 at 21:55 -0500, robert engels wrote:
> As I said, I reviewed the code - which you can do as well. It is
> below. At least for “unix-ish” systems - it goes to syscall.Read()
> which is why I linked you to the unix documentation on the difference
> between read() and recv().
>
> Instead of waiting for someone else to confirm, you can think about
> it logically - sending packet based messages as a stream would not
> work as you have no boundaries, and no ordering guarantees - so
> streaming them would be useless - it would require every protocol on
> top of UDP to have embedded length and framing information in order
> to detect packet starts. Not to mention it would be impossible to
> read the OOB data (like sender address - since a UDP socket can
> receive from multiple senders - so you would have no ability to know
> where the packet came from (unless bound to a single sender).
>
> udpsock.go -> net.go -> poll/fd_unix.go
>
> // Read implements io.Reader.
> func (fd *FD) Read(p []byte) (int, error) {
> if err := fd.readLock(); err != nil {
> return 0, err
> }
> defer fd.readUnlock()
> if len(p) == 0 {
> // If the caller wanted a zero byte read, return
> immediately
> // without trying (but after acquiring the readLock).
> // Otherwise syscall.Read returns 0, nil which looks
> like
> // io.EOF.
> // TODO(bradfitz): make it wait for readability? (Issue
> 15735)
> return 0, nil
> }
> if err := fd.pd.prepareRead(fd.isFile); err != nil {
> return 0, err
> }
> if fd.IsStream && len(p) > maxRW {
> p = p[:maxRW]
> }
> for {
> n, err := syscall.Read(fd.Sysfd, p)
> if err != nil {
> n = 0
> if err == syscall.EAGAIN && fd.pd.pollable() {
> if err = fd.pd.waitRead(fd.isFile); err
> == nil {
> continue
> }
> }
>
> // On MacOS we can see EINTR here if the user
> // pressed ^Z. See issue #22838.
> if runtime.GOOS == "darwin" && err ==
> syscall.EINTR {
> continue
> }
> }
> err = fd.eofError(n, err)
> return n, err
> }
> }
>
>
> >
> > On May 12, 2019, at 9:37 PM, Dan Kortschak <[email protected]>
> > wrote:
> >
> > Yes, I'm aware of all this. However, the net.UDPConn Read method
> > states
> > that it "Read implements the Conn Read method", and does not the
> > io.Reader interface; net.Conn has the explicit method, not an
> > embedding
> > of io.Reader.
> >
> > I'd like to hear from someone who contributed to net.
> >
> > On Sun, 2019-05-12 at 21:30 -0500, robert engels wrote:
> > >
> > > Which is a big problem with the Go “interface” specification…
> > >
> > > But the de-facto standard is as I stated - if it implements the
> > > method it implements the interface. There is no requirement that
> > > the
> > > method/struct “be documented” to be an implementor - buyer
> > > beware!
> > >
> > > We is also why you should never use method names that collide
> > > with
> > > “stdlib interfaces” unless you intend them to have the same
> > > semantics.
> > >
> > > >
> > > >
> > > > On May 12, 2019, at 8:58 PM, Dan Kortschak <[email protected]>
> > > > wrote:
> > > >
> > > > This is not quite true. The language itself doesn't make claims
> > > > other
> > > > than types and method names. However, there are conventions
> > > > around
> > > > the
> > > > semantics of methods in an interface. For example, a Read
> > > > method
> > > > that
> > > > returns 0, nil is allowed for io.Reader, but frowned upon
> > > > unless
> > > > the
> > > > buffer is zero length, and a Read method that fills the buffer
> > > > with
> > > > n
> > > > bytes and returns n-1 (or n+1), nil is not a correct
> > > > implementation
> > > > of
> > > > io.Reader. Nor is an implementation correct if it retains the
> > > > buffer.
> > > >
> > > > Just as the BDNF is not a complete definition of the grammar of
> > > > the
> > > > language, interface type decls are not complete definitions of
> > > > interfaces.
> > > >
> > > > This is why I am asking.
> > > >
> > > > On Sun, 2019-05-12 at 20:16 -0500, robert engels wrote:
> > > > >
> > > > >
> > > > > There is no claim because that is not how Go interfaces work
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/1557716698.29848.7.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.
