Hey all, this program exits (as expected) when run with macOS 10.12.6 + Go
1.8.6, but it deadlocks when run with Go 1.9.3:
https://play.golang.org/p/Dw_ND9gkgPm
The same behavior is observed when using unix.SetNonblock instead of
syscall.SetNonblock.
It appears that the SetNonblock() functio
I checked this on FreeBSD and it still works, so seems like it could be
a macOS specific issue.
You should raise a bug here:
https://github.com/golang/go/issues
It would be good to try and identify the go version which it first broke
in too, as that will be helpful in identifying the change wh
I tried on Linux/amd64 (debian testing, kernel 4.14.0-2-amd64) and it's
broken too:
* go 1.9.3 + syscall.SetNonblock : hangs in syscall.Read()
* go 1.9.3 + unix.SetNonblock: hangs in syscall.Read()
* go 1.9.2 + syscall.SetNonblock : hangs in syscall.Read()
* go 1.9.2 + unix.SetNonblock: h
Looking at the Linux stack trace, the culprit seems the next-to-last line:
-
fcntl(3, F_SETFL, O_RDONLY) = 0
read(3,
-
i.e. at least on Linux the O_NONBLOCK bit gets cleared immediately before
the read()
On Thursday, January 25, 2018 at 12:00:01 PM UTC+1, Max
On Wed, Jan 24, 2018 at 8:06 PM, Dave Keck wrote:
>
> Hey all, this program exits (as expected) when run with macOS 10.12.6 + Go
> 1.8.6, but it deadlocks when run with Go 1.9.3:
>
> https://play.golang.org/p/Dw_ND9gkgPm
>
> The same behavior is observed when using unix.SetNonblock instead of
Thanks for the explanation and the solution :)
Where is this behaviour documented?
The current documentation https://golang.org/pkg/os does not indicate
blocking vs non blocking behaviour of *os.File and of functions that return
*os.File, as for example os.Pipe()
Also, os.File.Fd() having side e
On Thu, Jan 25, 2018 at 7:04 AM, Max wrote:
>
> Thanks for the explanation and the solution :)
>
> Where is this behaviour documented?
>
> The current documentation https://golang.org/pkg/os does not indicate
> blocking vs non blocking behaviour of *os.File and of functions that return
> *os.File,
On 2018-01-25 16:18, Ian Lance Taylor wrote:
> On Thu, Jan 25, 2018 at 7:04 AM, Max wrote:
>> Also, os.File.Fd() having side effects seems very unexpected and surprising
>> at least to me.
.File() on a network conn have had that effect.
> I found it very difficult to write fully correct docume
Thanks all. I opened this issue:
https://github.com/golang/go/issues/23556
(The reason I'm using SetNonblock is that before Go 1.9, it wasn't safe to
call file.Close() if another goroutine was reading/writing to the pipe. But
now that it's safe with Go 1.9, I can re-organize my code and remov
