FAQ

On Thursday, February 28, 2013 3:31:54 PM UTC+2, Robert Obryk wrote:
+cc golang-dev
+bcc golang-nuts

Hello,

I would like to propose a change in the net package in the
{Read,Write}Msg* methods (they are to be new in Go1.1), so that they
allow flags to be passed in. As far as I know, the only way to read a
socket's error queue in Linux is to use recvmsg with MSG_ERRQUEUE flag
set. The {Read,Write}Msg methods don't allow flags to be passed in and
set them always to 0.
For what it's worth, in a big code base one only seems to end up
using ReadMsgUnix a few times, so this could probably fly.

Except, ReadMsgUnix already existed in Go 1:

http://golang.org/pkg/net/

so you can only change the IP and UDP ones according to the contract.

It doesn't seem like the flags for sending on the UNIX side are very
useful, so this is probably okay.

I propose that both ReadMsg* and WriteMsg* take an additional argument
for flags. This obviously exports system-specific flags out of the net
package, but we already do that in the other direction in these same
methods. ReadMsg should filter out MSG_WAITALL (because it seems
nonsensical or poorly defined for nonblocking operations); all other
flags from POSIX and Linux-specific ones seem not to interfere with
the assumptions related to the poll server or nonblocking behaviour. I
also propose that ReadMsgUnix set MSG_CMSG_CLOEXEC, for similar
reasons we set O_CLOEXEC in open() (although I'm not sure if that
shouldn't be the domain of someone who actually uses SCM_RIGHTS). For
If the file descriptor makes its way into the net.File* methods it gets
O_CLOEXEC set on it. For normal files you would have to do it manually,
which probably isn't ideal.

Potentially ParseUnixRights should do this before returning the file
descriptors to the caller, since MSG_CMSG_CLOEXEC only exists since Linux
2.6.23 (what is the minimum kernel for Go these days?) and might not exist
on the BSD flavours (the file code has special stuff for O_CLOEXEC on the
BSDs).

I think this might be worth a discussion and a CL by itself and probably
obviates the need for supporting MSG_CMSG_CLOEXEC in ReadMsgUnix.

Maybe fixing this now also violates the Go 1 contract.

WriteMsg* I didn't find any flags that would seem to interfere with
assumptions related to the poll server and nonblocking behaviour.

I will send a CL upon request; I didn't do it first because the
contributing guidelines strongly advise against that. This is a change
that, as far as I understand the backwards compatibility guarantees,
should be made before Go1.1 or not at all in the foreseeable future.
Regards

Albert

--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Robert Obryk at Feb 28, 2013 at 11:13 pm

    On Thursday, 28 February 2013 17:38:16 UTC+1, Albert Strasheim wrote:

    For what it's worth, in a big code base one only seems to end up
    using ReadMsgUnix a few times, so this could probably fly.

    Except, ReadMsgUnix already existed in Go 1:

    http://golang.org/pkg/net/

    so you can only change the IP and UDP ones according to the contract.

    It doesn't seem like the flags for sending on the Unix side are very
    useful, so this is probably okay.
    Thanks, somehow haven't noticed that *MsgUnix existed back there. Apart
    from the close-on-exec flag for ReadMsg, other flags don't seem to be
    useful for Unix sockets. In that case it'd probably be best to leave the
    Unix sockets alone.

    If the file descriptor makes its way into the net.File* methods it gets
    O_CLOEXEC set on it. For normal files you would have to do it manually,
    which probably isn't ideal.

    Potentially ParseUnixRights should do this before returning the file
    descriptors to the caller, since MSG_CMSG_CLOEXEC only exists since Linux
    2.6.23 (what is the minimum kernel for Go these days?) and might not exist
    on the BSD flavours (the file code has special stuff for O_CLOEXEC on the
    BSDs).
    I think this might be worth a discussion and a CL by itself and probably
    obviates the need for supporting MSG_CMSG_CLOEXEC in ReadMsgUnix.
    This is a different matter than the one I want to address now, but that
    won't really help by itself: the usual race condition with a fork-and-exec
    applies, so we'd need to hold the ForkLock in read mode during ReadMsg and
    ParseUnixRights, which doesn't seem desirable, because ReadMsg may block.
    But that seems to be a matter for a different CL.

    Thanks,
    Robert

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedFeb 28, '13 at 4:38p
activeFeb 28, '13 at 11:13p
posts2
users2
websitegolang.org

2 users in discussion

Albert Strasheim: 1 post Robert Obryk: 1 post

People

Translate

site design / logo © 2022 Grokbase