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

runtime: long sleep doesn't schedule #5321

Closed
gpaul opened this issue Apr 19, 2013 · 10 comments
Closed

runtime: long sleep doesn't schedule #5321

gpaul opened this issue Apr 19, 2013 · 10 comments
Milestone

Comments

@gpaul
Copy link
Contributor

gpaul commented Apr 19, 2013

Calling time.Sleep after 'go time.Sleep' blocks forever.

Eg.
go time.Sleep(1<<63-1)
time.Sleep(1)

However,
go time.Sleep(1<<62)
time.Sleep(1)

Works fine.

I've attached the source file and stack trace.

uname -a
Linux 3.3.8-1.fc16.x86_64 #1 SMP Mon Jun 4 20:49:02 UTC 2012 x86_64 x86_64 x86_64
GNU/Linux

go version devel +58f8a30f5b78 Tue Apr 16 14:20:06 2013 -0700 linux/amd64
@gpaul
Copy link
Contributor Author

gpaul commented Apr 19, 2013

Comment 1:

The captcha screwed my attempt at attaching files.

Attachments:

  1. sleep.trace (1299 bytes)
  2. sleep_test.go (259 bytes)

@ality
Copy link
Member

ality commented Apr 19, 2013

Comment 2:

The problem is that the timer code adds the duration to the current time (in
nanoseconds) resulting in a negative value which throws off the logic in the
timer proc.
I have a preliminary changeset but I'm curious about how we should handle this
case. Do we simply return as we do when the caller supplies a duration <= 0 or
do we sleep for the maximum time allowed by int64 constraints?

Labels changed: added priority-soon, removed priority-triage.

Owner changed to @ality.

Status changed to Accepted.

@adg
Copy link
Contributor

adg commented Apr 19, 2013

Comment 3:

I'm sure I already fixed this with http://golang.org/change/a7ea286f5569

@ality
Copy link
Member

ality commented Apr 19, 2013

Comment 4:

adg,
That fixed it for time.Timer but time.Sleep calls runtime·tsleep directly.

@ianlancetaylor
Copy link
Member

Comment 6:

I think it's correct to sleep for the maximum possible time.
I don't think this needs to be fixed for Go 1.1.  It's an edge case.

@ality
Copy link
Member

ality commented May 10, 2013

Comment 7:

Issue #5439 has been merged into this issue.

@davecheney
Copy link
Contributor

Comment 8:

Labels changed: added go1.2maybe.

@PieterD
Copy link
Contributor

PieterD commented Jul 29, 2013

Comment 9:

This Issue has been sitting here for a while, so I thought I'd take a rough stab at it.
https://golang.org/cl/12058050

@rsc
Copy link
Contributor

rsc commented Jul 30, 2013

Comment 10:

Labels changed: added go1.2, removed go1.2maybe.

Status changed to Started.

@ality
Copy link
Member

ality commented Sep 6, 2013

Comment 11:

This issue was closed by revision 3548ab5.

Status changed to Fixed.

@rsc rsc added this to the Go1.2 milestone Apr 14, 2015
@rsc rsc removed the go1.2 label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
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

8 participants