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

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:


And in more detail here:


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).


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

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 4 of 28 | next ›
Discussion Overview
groupgolang-nuts @
postedOct 26, '14 at 9:10a
activeOct 27, '14 at 7:01p



site design / logo © 2022 Grokbase