[go-nuts] How to handle write operation when the err is ErrShortWrite?

The io.Writer contract specifies that if less than len(buf) bytes are
written, an error must be returned.

Critically it does _not_ make any guarantees about the content or form of
that error message.

在 2014年10月8日星期三UTC+8下午9时52分20秒，Dave Cheney写道：
Thank you very much for your reply.

So how to handle the situation that less than len(buf) bytes are written?
If written in C with non-blocking io, if the write system call return less
than len(buf), we can add the write event to the epoll loop, and wait for
the next write call.

As far as I known, go use non-blocking io for system calls, so do I need to
handle this less than len(buf) bytes situation?
Like the for {} loop I wrote ? And if go does not make any guarantees about
the content or form of that error message, how can I know which err I
should deal with ?

Or does go guarantees that if less than len(buf) bytes returned, I don't
need to send the rest of the data?

Go will write all the bytes you want, except in case of error.
In essence: go runtime includes the for loop.

在 2014年10月9日星期四UTC+8下午12时35分00秒，Tamás Gulácsi写道：

So what I have to write is codes like the following one ? No need to check
the returned lenght?
So what is that return value used for?


                     if writeLen, err :=
conn.Write(writeBuf[writePos:writeDataLen]); err != nil {
                         commlog.LogErr("Write to %s failed err %s",
connFrom, err.Error())
                         return
                     } else {
                         //do something else
                     }

It depends. There will be an error if written length is less than the wanted. You have to decide what to do based on the error and your goals.

在 2014年10月9日星期四UTC+8下午2时27分01秒，Tamás Gulácsi写道：


when the return length is less than len(buf), what I want is:
1. if the err indicates that I can call the write again, than I will call
the write again to send the reset of the data
for example, in C code, if the errno is EAGAIN when using non-blocking IO,
I will know that I can call the write system call again
Is there some err like this one ?

2. if the err indicates that it's some kind of other error (like the
connection is closed by the peer), than I will close the connection and
return fail

And what confuse me is that I don't know how to distinguish these two type
of error.

I found it difficult to find the return err message from the api page, from
the official website, all I can found is this:


         // Write writes data to the connection.
         // Write can be made to time out and return a Error with Timeout() == true
         // after a fixed time limit; see SetDeadline and SetWriteDeadline.
         Write(b []byte <http://golang.org/pkg/builtin/#byte>) (n int <http://golang.org/pkg/builtin/#int>, err error <http://golang.org/pkg/builtin/#error>)
So the Write call return an error var, and what does this error var mean?
How can I know what kind of error is?
After search the web, I found that this err var maybe implement the net.Error interface or maybe an net.OpError struce, but what message can I got from this interface or strut?

Take the net.Error interface for example, this is the definition of the interface:

type Error interface {
         error <http://golang.org/pkg/builtin/#error>
         Timeout() bool <http://golang.org/pkg/builtin/#bool> // Is the error a timeout?
         Temporary() bool <http://golang.org/pkg/builtin/#bool> // Is the error temporary?
}

From the interface, I can know that if the err var implements this interface, I can use the Timeout() or Temporary() func to know if the error is an timeout error or an temporary error.
I know what timeout means, but what does temporary error means?

Does it means I can call the Write call again? Where can I found the definition of Temporary?

And what about oter kind of error? Like the connection closed by the peer, how can I know this type of error?

And for net.OpError, this is the definition:
type OpError struct {
         // Op is the operation which caused the error, such as
         // "read" or "write".
         Op string <http://golang.org/pkg/builtin/#string>

         // Net is the network type on which this error occurred,
         // such as "tcp" or "udp6".
         Net string <http://golang.org/pkg/builtin/#string>

         // Addr is the network address on which this error occurred.
         Addr Addr <http://golang.org/pkg/net/#Addr>

         // Err is the error that occurred during the operation.
         Err error <http://golang.org/pkg/builtin/#error>
}


Again, from the comments of the definition, I don't know how to find the exact type of the error.
Do I have to use regex to find the pattern of the error string to find out what kind of error it is?

And I notice that the error can also be an syscall.Errno type, is this type enough for distinguish the error type?
And which func in the net package will return this type of error? Is there any document I can read from ?


thanks

You cannot observe Go's use of non blocking IO from a Go program. From
the POV of a single goroutine Read or Write _always_ blocks.
What I and the other contributors are trying to say is you have two states

1. err == nil, everything worked
2. err != nil, something failed, that's all we know

You _could_ try to use a type assertion or type switch to interrogate
the value inside the error, but you'll find that few packages give any
suggestion of what error will returned.

在 2014年10月9日星期四UTC+8下午4时58分08秒，Dave Cheney写道：
Dave, thank you very much for your explaination.
Still I have one question, in C code, when deal with blocking io, we will
have the handle one situation, which is that the errno is EINTR.
If I call read or write and the errno is EINTR, I will call read/write
again.

So do I have to handle this situation within GO ?

Do I have to wirte code like this?

func checkNetErr(err error) bool
{

     if ne, ok := err.(*net.OpError); ok
{

         if errno, enok := ne.Err.(syscall.Errno); enok
{

             if errno == syscall.EINTR
{

                 return
true


}


}


}

     return
false

}


  if readLen, err := conn.Read(readBuf[readPos:maxReadBufSize]); err != nil {
                     if checkNetErr(err) {
                         continue
                     }
                     if err == io.EOF {
                         commlog.LogErr("maybe client disconnect %s %s",
connFrom, err.Error())
                     } else {
                         commlog.LogErr("Read from %s failed err %s",
connFrom, err.Error())
                     }
                     break
                 }




I understand these two rules.

But what I don't know how to deal with is the second situation, which is
err != nil.
I can't get an clear information with the err var, like you said, I can try
to use a type assertion or type switch to interrogate
the value inside the error, but how to know exactly what kind of error it
is, and how to deal with it ?
It seems that there is no clear or easy way.

As I said the for cycle which retries writing where possible (the error is not an error, or eventually it will succeed), is in the Go runtime (for sockets).
So you won't get EAGAIN.

在 2014年10月9日星期四UTC+8下午8时18分39秒，Tamás Gulácsi写道：

So I don't need to handle EAGAIN, Go runtime will do the retry until
timeout, and if I got an error, that means it's an error that can't be
retry, all I have to do is deal with this error, like close the connection,
is this understanding right?

If so, does this means I don't need to handle EINTR either？

Thank you very much for your patience!

Nope. Go handles that for you, we tell the signal handlers to restart any
restartable syscall.s

At this point I think you need to step out of the theoretical and wrote
some test code to validate the questions you have about Go.

在 2014年10月9日星期四UTC+8下午9时49分51秒，Dave Cheney写道：
To Dave and Tamás,

thanks for your patience and explaination, I think I understand the
question now.

Actually all these questions coming out when I'm writting some code.
And to be honest, I think the Go doc page is a bit confusing or lack of
information, if it can be as clear as the man page, then I think it would
be much easyer to understand, writting some test code would be helpful but
without an clear definition it would be just guessing.

Thanks very much for your time.

You can find the contract for an io.Writer alongside the documentation
for package io. Net.Conn just implements this contract. Still, even that
documentation might not be as specific as your system's man page for the
write system call.

The reason for that is as follows: the man page author generally knows
on what kinds of file descriptors (i.e. referring to sockets, local
files, ttys, …) write(2) can be called and just describes the union of
their quirks.

That's not possible with Go interfaces. You have the interface contract
and an unbounded number of possible implementations. There isn't any
answer more specific than Dave's while still being general, that is,
applicable to any given io.Writer.

Some implementations do give you more information that you can
programmatically check for. You already discovered the error types in
net or the possibility to return syscall.Errno values and the more
generic errors from package io. Most of the latter, I think, are newer
than the io.Writer contract itself. They might become the conventional
way of communicating IO errors.

Lars

For the sake of correctness: net.Conn doesn't implement anything, it
just passes the contract on.