Skip to content
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

syscall: Dup3/Dup2/Dup should not use RawSyscall #10202

Closed
jacobsa opened this issue Mar 20, 2015 · 1 comment
Closed

syscall: Dup3/Dup2/Dup should not use RawSyscall #10202

jacobsa opened this issue Mar 20, 2015 · 1 comment
Milestone

Comments

@jacobsa
Copy link
Contributor

jacobsa commented Mar 20, 2015

These syscalls may block if there is a FUSE file system involved, causing them to camp on GOMAXPROCS credit. See this thread for details and discussion.

@minux minux added this to the Go1.5 milestone Mar 20, 2015
ianlancetaylor added a commit to golang/sys that referenced this issue Mar 26, 2015
This avoids hanging when a Go program uses a FUSE filesystem and the
dup system call has to close a file descriptor.  When dup uses
RawSyscall then the goroutine calling dup will occupy a scheduler slot
(a p structure) during the call, and may block waiting for some other
goroutine to respond to the close call on the FUSE filesystem.
Changing to Syscall avoids the problem.  This makes Dup a tiny bit
slower but is quite unlikely to make a difference for any real
programs.

Update golang/go#10202.

Change-Id: I590c5c9a04e0a1281a85dc553c7592fa83949ac7
Reviewed-on: https://go-review.googlesource.com/8056
Reviewed-by: Rob Pike <r@golang.org>
@jacobsa
Copy link
Contributor Author

jacobsa commented Mar 26, 2015

Just for the record, I see that you hit golang.org/x/sys/unix with golang/sys@5829c74, too. Thank you!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants