Comment 1:

The sendmsg system call always either sends the entire message or returns an error with
EMSGSIZE.  Under what circumstances can the wrong result be reported?  Can you show a
test case?

Labels changed: added repo-main.

Comment 2 by alexander.larsson:

For unix sockets (SOCK_STREAM) a WriteMsgUnix() call works just like Write(). It writes
as much as it can until the socket buffer is full, then it returns the number of bytes
written. EMSGSIZE is only returned for SOCK_DGRAM sockets.
Attaching a simple example that uses UnixConn.WriteMsgUnix() with a large buffer.
Here is the output i get from it:
$ go run sendmsg.go
Result from WriteMsgUnix, bytes written: 1073741824, error: <nil>
read 219264 bytes
This is with a completely empty socket queue. If there is less space in it less would be
written.
In this particular case you can use Write() instead, but in my case I need WriteMsgUnix
because i need to send some oob data too (file descriptor passing).

Comment 3 by alexander.larsson:

Somehow the attachment didn't get attached. Trying again.

Attachments:

1. sendmsg.go (1071 bytes)

Comment 4:

Thanks for the example.  That is not good.
We can't change syscall.SendMsg, because that would break the Go 1 guarantee.  But I
guess we could introduce another function to syscall that calls sendmsg and returns the
number of bytes written.  And we could change netFD.WriteMsg to call that.

Labels changed: added release-go1.3maybe.

Comment 5:

This issue was updated by revision a7858a4.

LGTM=aram, iant
R=iant, aram, bradfitz
CC=golang-codereviews
https://golang.org/cl/81210043

Comment 6:

Status changed to Started.

Comment 7:

Status changed to New.

Comment 8:

What's the status of this, Mikioh? Are we going to switch to using syscall.SendMsgN now?

Comment 9:

nope, still work on and will send a cl later; i mean, just did flush
my cl/issue queues to avoid buffer bloat. sorry for the confusion.

Comment 10:

CL https://golang.org/cl/85630044 mentions this issue.

Comment 11:

CL https://golang.org/cl/90170046 mentions this issue.

Comment 12:

This issue was closed by revision e419ab6.

Status changed to Fixed.

Comment 13:

CL https://golang.org/cl/98790044 mentions this issue.

Comment 14:

This issue was updated by revision d873e64.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/98790044