FAQ
Hi everyone,

I'm learning go by implementing modbus protocol [1]. It is pretty usable
but only tested against a simulator at the moment.

However, I'm facing a problem with detecting data available from serial
port fd.
In order to have a sort of reading timeout, I have to use a silly
loop+sleep:

https://github.com/goburrow/modbus/blob/master/serial_linux.go#L110

And I'm considering to use syscall.Select on the file fd, which is like:

var rfds syscall.FdSet
FD_SET(file.Fd(), rfds)
n, err := syscall.Select(int(file.Fd()) + 1, &rfds, nil, nil, &timeout)

But I'm not sure how to implement FD_SET here. I searched through the forum
but haven't found the answer or any example of using select.
Do we have an alternative way to have a SetReadDeadline for File like Conn
in net package?

Thank you
--
qvn

[1] https://github.com/goburrow/modbus

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

  • Nick Patavalis at Oct 26, 2014 at 2:48 pm
    I think this will prove useful to you:

       https://github.com/npat-efault/poller

    I wrote the library specifically for applications like the one you are
    implementing,
    and it has worked quite well for me.

    Give it a try...

    /npat
    On Sunday, October 26, 2014 11:10:33 AM UTC+2, Quoc-Viet Nguyen wrote:

    Hi everyone,

    I'm learning go by implementing modbus protocol [1]. It is pretty usable
    but only tested against a simulator at the moment.

    However, I'm facing a problem with detecting data available from serial
    port fd.
    In order to have a sort of reading timeout, I have to use a silly
    loop+sleep:

    https://github.com/goburrow/modbus/blob/master/serial_linux.go#L110

    And I'm considering to use syscall.Select on the file fd, which is like:

    var rfds syscall.FdSet
    FD_SET(file.Fd(), rfds)
    n, err := syscall.Select(int(file.Fd()) + 1, &rfds, nil, nil, &timeout)

    But I'm not sure how to implement FD_SET here. I searched through the
    forum but haven't found the answer or any example of using select.
    Do we have an alternative way to have a SetReadDeadline for File like Conn
    in net package?

    Thank you
    --
    qvn

    [1] https://github.com/goburrow/modbus
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Taylor at Oct 27, 2014 at 3:35 am

    On Sun, Oct 26, 2014 at 2:10 AM, Quoc-Viet Nguyen wrote:
    I'm learning go by implementing modbus protocol [1]. It is pretty usable but
    only tested against a simulator at the moment.

    However, I'm facing a problem with detecting data available from serial port
    fd.
    In order to have a sort of reading timeout, I have to use a silly
    loop+sleep:

    https://github.com/goburrow/modbus/blob/master/serial_linux.go#L110

    And I'm considering to use syscall.Select on the file fd, which is like:

    var rfds syscall.FdSet
    FD_SET(file.Fd(), rfds)
    n, err := syscall.Select(int(file.Fd()) + 1, &rfds, nil, nil, &timeout)

    But I'm not sure how to implement FD_SET here. I searched through the forum
    but haven't found the answer or any example of using select.
    Do we have an alternative way to have a SetReadDeadline for File like Conn
    in net package?
    I wouldn't worry about using select. Instead have a goroutine that
    does blocking reads and writes the data to a channel. Then other
    goroutines can handle the timeout using a Go select statement.

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Oct 27, 2014 at 6:13 am

    On Monday, October 27, 2014 5:35:23 AM UTC+2, Ian Lance Taylor wrote:

    I wouldn't worry about using select. Instead have a goroutine that
    does blocking reads and writes the data to a channel. Then other
    goroutines can handle the timeout using a Go select statement.
    Yes, but when the timeout is detected you need to, somehow, notify the
    "reading" goroutine (which will probably be blocked inside read(2)) to
    abort. An obvious way do it is by closing the respective FD. I'm *not* sure
    if close(2) is *guaranteed* to wake-up the blocked goroutine (and force it
    to return from the read(2) call with an error), but let's assume it is. Even
    so, this may introduce subtle race conditions and must be coded very
    defensively.

    There is a warning about this in the Linux close(2) man page:

    It is probably unwise to close file descriptors while they may be in use by
    system calls in other threads in the same process. Since a file descriptor
    may be reused, there are some obscure race conditions that may cause
    unintended side effects.


    The issue is also discussed in some length here:

    https://docs.fedoraproject.org/en-US/Fedora_Security_Team//html/Defensive_Coding/sect-Defensive_Coding-Tasks-Descriptors.html


    And in more detail here:

    http://www.drdobbs.com/parallel/file-descriptors-and-multithreaded-progr/212001285


    I'm not saying it can't be done; you just have to tread cautiously...

    Using my "poller" package is, maybe, easier and, probably, a bit more
    efficient (assuming, of course, that there are no SNAFUs in it).

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Quoc-Viet Nguyen at Oct 27, 2014 at 1:16 pm
    Thanks, Nick

    I believe your poller would work but I was looking for a lightweight
    solution so I gave Select another try and it seems working now.

    https://github.com/goburrow/modbus/blob/master/serial_linux.go#L106

    BTW, any suggestions on my fd_set and fd_isset? They're a bit ugly though.

    Cheers


    On Mon, Oct 27, 2014 at 4:12 PM, Nick Patavalis
    wrote:
    On Monday, October 27, 2014 5:35:23 AM UTC+2, Ian Lance Taylor wrote:


    I wouldn't worry about using select. Instead have a goroutine that
    does blocking reads and writes the data to a channel. Then other
    goroutines can handle the timeout using a Go select statement.
    Yes, but when the timeout is detected you need to, somehow, notify the
    "reading" goroutine (which will probably be blocked inside read(2)) to
    abort. An obvious way do it is by closing the respective FD. I'm *not* sure
    if close(2) is *guaranteed* to wake-up the blocked goroutine (and force it
    to return from the read(2) call with an error), but let's assume it is. Even
    so, this may introduce subtle race conditions and must be coded very
    defensively.

    There is a warning about this in the Linux close(2) man page:

    It is probably unwise to close file descriptors while they may be in use by
    system calls in other threads in the same process. Since a file descriptor
    may be reused, there are some obscure race conditions that may cause
    unintended side effects.


    The issue is also discussed in some length here:

    https://docs.fedoraproject.org/en-US/Fedora_Security_Team//html/Defensive_Coding/sect-Defensive_Coding-Tasks-Descriptors.html


    And in more detail here:

    http://www.drdobbs.com/parallel/file-descriptors-and-multithreaded-progr/212001285


    I'm not saying it can't be done; you just have to tread cautiously...

    Using my "poller" package is, maybe, easier and, probably, a bit more
    efficient (assuming, of course, that there are no SNAFUs in it).

    /npat


    --
    Quoc-Viet (Kevin) Nguyen

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Ian Taylor at Oct 27, 2014 at 3:09 pm

    On Sun, Oct 26, 2014 at 11:12 PM, Nick Patavalis wrote:
    On Monday, October 27, 2014 5:35:23 AM UTC+2, Ian Lance Taylor wrote:


    I wouldn't worry about using select. Instead have a goroutine that
    does blocking reads and writes the data to a channel. Then other
    goroutines can handle the timeout using a Go select statement.
    Yes, but when the timeout is detected you need to, somehow, notify the
    "reading" goroutine (which will probably be blocked inside read(2)) to
    abort.
    Why?

    Ian

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Oct 27, 2014 at 4:21 pm

    On Monday, October 27, 2014 5:09:30 PM UTC+2, Ian Lance Taylor wrote:
    On Sun, Oct 26, 2014 at 11:12 PM, Nick Patavalis
    <nick.pa...@gmail.com <javascript:>> wrote:
    On Monday, October 27, 2014 5:35:23 AM UTC+2, Ian Lance Taylor wrote:


    I wouldn't worry about using select. Instead have a goroutine that
    does blocking reads and writes the data to a channel. Then other
    goroutines can handle the timeout using a Go select statement.
    Yes, but when the timeout is detected you need to, somehow, notify the
    "reading" goroutine (which will probably be blocked inside read(2)) to
    abort.
    Why?

    Hmmm.... So what you mean is that, once an FD is opened, you start a
    goroutine reading from it and writing data to a channel, and leave it there
    running.... forever. Whenever you want to read from the FD you actually
    read from the channel. Yes, it could work.

    Eventually, you will, though, have to stop this goroutine (somehow) even if
    it is when you no longer need the FD (i.e. when it's time to close it), and
    again, you have to do it "carefully"---for the reasons described above.

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Oct 27, 2014 at 4:27 pm
    Close the file in those cases. That will unblock the reading goroutine.

    On Mon Oct 27 2014 at 2:21:43 PM Nick Patavalis wrote:


    On Monday, October 27, 2014 5:09:30 PM UTC+2, Ian Lance Taylor wrote:

    On Sun, Oct 26, 2014 at 11:12 PM, Nick Patavalis
    wrote:
    On Monday, October 27, 2014 5:35:23 AM UTC+2, Ian Lance Taylor wrote:


    I wouldn't worry about using select. Instead have a goroutine that
    does blocking reads and writes the data to a channel. Then other
    goroutines can handle the timeout using a Go select statement.
    Yes, but when the timeout is detected you need to, somehow, notify the
    "reading" goroutine (which will probably be blocked inside read(2)) to
    abort.
    Why?

    Hmmm.... So what you mean is that, once an FD is opened, you start a
    goroutine reading from it and writing data to a channel, and leave it there
    running.... forever. Whenever you want to read from the FD you actually
    read from the channel. Yes, it could work.

    Eventually, you will, though, have to stop this goroutine (somehow) even
    if it is when you no longer need the FD (i.e. when it's time to close it),
    and again, you have to do it "carefully"---for the reasons described above.

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Oct 27, 2014 at 4:33 pm

    On Monday, October 27, 2014 6:27:21 PM UTC+2, Gustavo Niemeyer wrote:

    Close the file in those cases. That will unblock the reading goroutine.

    Yes, If, at the exact instance you call "close()", the goroutine is, in
    fact, blocked on read(2). If not (e.g. if it's *about* to call read again)
    you risk the chance of it reading from another FD...

    /npat


    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Oct 27, 2014 at 4:36 pm

    On Monday, October 27, 2014 6:33:27 PM UTC+2, Nick Patavalis wrote:
    Yes, If, at the exact instance you call "close()", the goroutine is, in
    fact, blocked on read(2). If not (e.g. if it's *about* to call read again)
    you risk the chance of it reading from another FD...
    s/instance/instant

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Oct 27, 2014 at 4:39 pm
    I don't understand what you're alluding to. If you call read on a closed
    fd, you get an appropriate error saying you're attempting to do so.


    On Mon Oct 27 2014 at 2:37:01 PM Nick Patavalis wrote:


    On Monday, October 27, 2014 6:33:27 PM UTC+2, Nick Patavalis wrote:

    Yes, If, at the exact instance you call "close()", the goroutine is, in
    fact, blocked on read(2). If not (e.g. if it's *about* to call read again)
    you risk the chance of it reading from another FD...
    s/instance/instant

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Oct 27, 2014 at 4:42 pm

    On Monday, October 27, 2014 6:39:50 PM UTC+2, Gustavo Niemeyer wrote:

    I don't understand what you're alluding to. If you call read on a closed
    fd, you get an appropriate error saying you're attempting to do so.

    Not if between your close() and the goroutine's read() another (unrelated)
    goroutine has called open() and the fd-number gets reused.

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • James Bardin at Oct 27, 2014 at 4:48 pm

    On Monday, October 27, 2014 12:42:17 PM UTC-4, Nick Patavalis wrote:

    On Monday, October 27, 2014 6:39:50 PM UTC+2, Gustavo Niemeyer wrote:


    I don't understand what you're alluding to. If you call read on a closed
    fd, you get an appropriate error saying you're attempting to do so.

    Not if between your close() and the goroutine's read() another (unrelated)
    goroutine has called open() and the fd-number gets reused.
    Have you confirmed that the runtime doesn't handle this correctly already?
    You shouldn't be calling syscall.Close(fd) to close the fd directly, you
    should be using the file's Close() method.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Oct 27, 2014 at 4:53 pm

    On Monday, October 27, 2014 6:48:24 PM UTC+2, James Bardin wrote:

    you should be using the file's Close() method.
    Which, if I'm not mistaken, just calls syscall.Close()

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Oct 27, 2014 at 5:02 pm

    On Monday, October 27, 2014 6:53:26 PM UTC+2, Nick Patavalis wrote:

    On Monday, October 27, 2014 6:48:24 PM UTC+2, James Bardin wrote:


    you should be using the file's Close() method.
    Which, if I'm not mistaken, just calls syscall.Close()
    Please notice that I'm *not* saying that the problem is "unsolvable". It
    just need to be coded "carefully" (some locking will / may be required).

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Oct 27, 2014 at 5:40 pm
    It does more than that, including setting the fd to -1. There might be an
    argument towards making that procedure safer when performed concurrently,
    though, so that Close+Read will necessarily behave correctly. I suggest
    opening an issue for that.
    On Mon Oct 27 2014 at 2:53:39 PM Nick Patavalis wrote:


    On Monday, October 27, 2014 6:48:24 PM UTC+2, James Bardin wrote:


    you should be using the file's Close() method.
    Which, if I'm not mistaken, just calls syscall.Close()

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Oct 27, 2014 at 6:03 pm
    In fact, I was looking at the os package, but netFD in the net package
    seems to be well behaved in this case, even when facing concurrency.



    On Mon Oct 27 2014 at 3:40:51 PM Gustavo Niemeyer wrote:

    It does more than that, including setting the fd to -1. There might be an
    argument towards making that procedure safer when performed concurrently,
    though, so that Close+Read will necessarily behave correctly. I suggest
    opening an issue for that.
    On Mon Oct 27 2014 at 2:53:39 PM Nick Patavalis wrote:


    On Monday, October 27, 2014 6:48:24 PM UTC+2, James Bardin wrote:


    you should be using the file's Close() method.
    Which, if I'm not mistaken, just calls syscall.Close()

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Oct 27, 2014 at 6:09 pm

    On Monday, October 27, 2014 8:04:03 PM UTC+2, Gustavo Niemeyer wrote:
    In fact, I was looking at the os package, but netFD in the net package
    seems to be well behaved in this case, even when facing concurrency.

    Yes, netFD is a totally different beast. All these problems are solved for
    network connections. It also provides a very robust implementation for
    reading / writting with timeouts and more...

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Oct 27, 2014 at 6:18 pm
    Okay, I was thinking in the context of network communication, which is
    where I have often exercised the logic suggested.

    For local file descriptors, the situation is indeed less clear when you
    want to interact with serial buses or the such. That said, the amount of
    boilerplate I had to figure out for having a serial line properly working
    from Go [1] was in itself a much more time consuming task than figuring how
    to close the file descriptor without races. I'm not saying what you suggest
    is not a problem, but it's a tiny part of having things working at all in
    those scenarios.

    [1] With a thermal printer, in that case.
    On Mon Oct 27 2014 at 4:09:40 PM Nick Patavalis wrote:


    On Monday, October 27, 2014 8:04:03 PM UTC+2, Gustavo Niemeyer wrote:

    In fact, I was looking at the os package, but netFD in the net package
    seems to be well behaved in this case, even when facing concurrency.

    Yes, netFD is a totally different beast. All these problems are solved for
    network connections. It also provides a very robust implementation for
    reading / writting with timeouts and more...

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • James Bardin at Oct 27, 2014 at 6:21 pm
    Not to veer too far off topic here, but there was talk some time ago about
    exposing a version of the runtime network poller for use on files in
    general. That would also be nice for the rare occasion when you have many
    files open, and don't want to end up with an excessive number of OS threads
    blocked in IO.

    I wonder if there ever any work on that proposal.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Oct 27, 2014 at 6:26 pm
    I believe that's golang.org/issue/6817
    On Mon Oct 27 2014 at 4:21:51 PM James Bardin wrote:



    Not to veer too far off topic here, but there was talk some time ago about
    exposing a version of the runtime network poller for use on files in
    general. That would also be nice for the rare occasion when you have many
    files open, and don't want to end up with an excessive number of OS threads
    blocked in IO.

    I wonder if there ever any work on that proposal.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Dmitry Vyukov at Oct 27, 2014 at 6:47 pm
    Can't you do it today with net.FileConn:
    http://golang.org/pkg/net/#FileConn
    ? I had an impression that you can.
    On Mon, Oct 27, 2014 at 10:26 PM, Gustavo Niemeyer wrote:
    I believe that's golang.org/issue/6817

    On Mon Oct 27 2014 at 4:21:51 PM James Bardin wrote:



    Not to veer too far off topic here, but there was talk some time ago about
    exposing a version of the runtime network poller for use on files in
    general. That would also be nice for the rare occasion when you have many
    files open, and don't want to end up with an excessive number of OS threads
    blocked in IO.

    I wonder if there ever any work on that proposal.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Oct 27, 2014 at 7:01 pm

    On Monday, October 27, 2014 8:47:55 PM UTC+2, Dmitry Vyukov wrote:
    Can't you do it today with net.FileConn:
    http://golang.org/pkg/net/#FileConn
    ? I had an impression that you can.
    No you can't.

    One of the first things FileConn() does is to call GetSockoptInt() on the
    fd which, in my case, will fail---since fd the does not correspond to a
    socket.

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Oct 27, 2014 at 6:39 pm
    Yes, the kind of programs I write, very often need to interact with
    hardware / kernel-services through device nodes. A LOT of device nodes. I
    would also love to see netpoller-like support for such cases. Not only for
    safer / more robust interactions, but also to avoid having one OS thread
    for every blocked operation.

    A while ago I patched the standard library to do just that, and it worked
    fine, but the exported interface was rather ugly (and also very
    Unix-specific) to even think that it could be officially supported.

    Then, I wrote the "poller" package which does---very roughly---what
    netpoller does, without special support from the runtime (albeit less
    efficiently) and I'm using that instead.

    Anyway, I'm veering off topic...
    On Monday, October 27, 2014 8:21:38 PM UTC+2, James Bardin wrote:



    Not to veer too far off topic here, but there was talk some time ago about
    exposing a version of the runtime network poller for use on files in
    general. That would also be nice for the rare occasion when you have many
    files open, and don't want to end up with an excessive number of OS threads
    blocked in IO.

    I wonder if there ever any work on that proposal.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Oct 27, 2014 at 6:47 pm
    Understood. That looks like a vote for http://golang.org/issue/6817 then.
    On Mon Oct 27 2014 at 4:39:25 PM Nick Patavalis wrote:

    Yes, the kind of programs I write, very often need to interact with
    hardware / kernel-services through device nodes. A LOT of device nodes. I
    would also love to see netpoller-like support for such cases. Not only for
    safer / more robust interactions, but also to avoid having one OS thread
    for every blocked operation.

    A while ago I patched the standard library to do just that, and it worked
    fine, but the exported interface was rather ugly (and also very
    Unix-specific) to even think that it could be officially supported.

    Then, I wrote the "poller" package which does---very roughly---what
    netpoller does, without special support from the runtime (albeit less
    efficiently) and I'm using that instead.

    Anyway, I'm veering off topic...

    On Monday, October 27, 2014 8:21:38 PM UTC+2, James Bardin wrote:



    Not to veer too far off topic here, but there was talk some time ago
    about exposing a version of the runtime network poller for use on files in
    general. That would also be nice for the rare occasion when you have many
    files open, and don't want to end up with an excessive number of OS threads
    blocked in IO.

    I wonder if there ever any work on that proposal.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Oct 27, 2014 at 6:05 pm

    On Monday, October 27, 2014 7:41:05 PM UTC+2, Gustavo Niemeyer wrote:
    It does more than that, including setting the fd to -1. There might be an
    argument towards making that procedure safer when performed concurrently,
    though, so that Close+Read will necessarily behave correctly. I suggest
    opening an issue for that.
    Yes, though not "atomically" (with syscall.Close()), which leaves a
    race-window open (a small one, but still...)

    Even setting fd to -1, by itself, is not "technically" safe...

    Is it in the intentions of the library authors for someone to be able to
    call Close + Read concurrently?

    Also, is it guaranteed that close() will wake-up threads blocked on read()?
    I haven't been able to find a (reasonably) definitive answer...

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Gustavo Niemeyer at Oct 27, 2014 at 6:09 pm
    Have you had a look at the code? The claims you have been making do not
    match the implementation at all. It's not just syscall.Close, thread do not
    block on read, there is locking involved, etc.



    On Mon Oct 27 2014 at 4:05:22 PM Nick Patavalis wrote:


    On Monday, October 27, 2014 7:41:05 PM UTC+2, Gustavo Niemeyer wrote:

    It does more than that, including setting the fd to -1. There might be an
    argument towards making that procedure safer when performed concurrently,
    though, so that Close+Read will necessarily behave correctly. I suggest
    opening an issue for that.
    Yes, though not "atomically" (with syscall.Close()), which leaves a
    race-window open (a small one, but still...)

    Even setting fd to -1, by itself, is not "technically" safe...

    Is it in the intentions of the library authors for someone to be able to
    call Close + Read concurrently?

    Also, is it guaranteed that close() will wake-up threads blocked on
    read()? I haven't been able to find a (reasonably) definitive answer...

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Nick Patavalis at Oct 27, 2014 at 6:14 pm

    On Monday, October 27, 2014 8:09:34 PM UTC+2, Gustavo Niemeyer wrote:

    Have you had a look at the code? The claims you have been making do not
    match the implementation at all. It's not just syscall.Close, thread do not
    block on read, there is locking involved, etc.

    What claims? Are you talking about netFD, or os.File?

    /npat

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedOct 26, '14 at 9:10a
activeOct 27, '14 at 7:01p
posts28
users6
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase