No worries. Thanks for trying.
Dan
On Sun, 2019-05-12 at 22:10 -0500, robert engels wrote:
> I am sorry if you think I was not helpful, nor friendly - I was
> trying to be both.
>
> That is why I took the time to pass on the relevant documentation,
> and code.
>
> >
> > On May 12, 2019, at 10:04 PM, Dan Kortschak <d...@kortschak.io>
> > wrote:
> >
> > 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 <d...@kortschak.io>
> > > > 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 <dan@kortschak.i
> > > > > > o>
> > > > > > 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 golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/1557717306.2642.0.camel%40kortschak.io.
For more options, visit https://groups.google.com/d/optout.
