-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux: open namepipe file may cause process hang #33050
Comments
root@ecs-88d2-:/home/# mkfifo xx open it like this: if no data write into pipe, it will block in Open() even the file has been deleted. |
This is intended behavior.
|
i my scenario, client don't know when peer write data, it should block to read the pipe. |
@hwhe It's the same behavior with any tools using
In other terminal:
And see |
yes, you are right, |
Yes, it's the standard behavior, and you can't go beyond it. The You can read open for more details. |
I would read from the pipe in a separate goroutine, and pass the read results into a channel that is read by the main goroutine. Then, check in the main routine if the FIFO still exists, if not, stop the separate goroutine. |
if the call Open() goroutine is blocked, how to stop it? |
I would use os.OpenFile with os.O_RDWR, then spin around trying to read in a loop, controlled by a boolean protected with a mutex if neccesary. |
This is how GNU/Linux works, and there is nothing we can do about it in the Go library, so closing the issue. You can continue to discuss it here if you like, or perhaps a GNU/Linux or general Unix forum would be appropriate. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
i create a pipe file, if no data write ,it will block on open() function.
when i delete this pipe file, the open() function will hang forever. it may cause fd leak.
It is a reasonable behavior?
What did you expect to see?
delete the pipe file, the Open() should return an error
What did you see instead?
block forever
goroutine 6269 [syscall, 34 minutes]:
syscall.Syscall6(0x101, 0xffffffffffffff9c, 0xc4209a7480, 0x80000, 0x0, 0x0, 0x0, 0x2, 0x2, 0x8abd30)
/root/buildbox/go-1.8.1/src/syscall/asm_linux_amd64.s:44 +0x5
syscall.openat(0xffffffffffffff9c, 0xc420294a80, 0x76, 0x80000, 0x10000c400000000, 0x8, 0x8, 0xc420388270)
/root/buildbox/go-1.8.1/src/syscall/zsyscall_linux_amd64.go:40 +0xd0
syscall.Open(0xc420294a80, 0x76, 0x80000, 0xc400000000, 0x4147ad, 0x41470f, 0xc42019aee8)
/root/buildbox/go-1.8.1/src/syscall/syscall_linux.go:51 +0x50
os.OpenFile(0xc420294a80, 0x76, 0x0, 0x0, 0xc42019af30, 0xc42019af28, 0xc4208de0f0)
/root/buildbox/go-1.8.1/src/os/file_unix.go:97 +0x80
os.Open(0xc420294a80, 0x76, 0x34, 0xc42019af78, 0x2)
/root/buildbox/go-1.8.1/src/os/file.go:247 +0x46
The text was updated successfully, but these errors were encountered: