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

don't use contexts for deadlines #58

Merged
merged 7 commits into from
May 22, 2019
Merged

don't use contexts for deadlines #58

merged 7 commits into from
May 22, 2019

Conversation

vyzo
Copy link
Contributor

@vyzo vyzo commented May 22, 2019

We are creating tons of contexts when there are deadlines... one for every read/write.

@vyzo vyzo requested a review from Stebalien May 22, 2019 19:38
@vyzo vyzo force-pushed the fix/reuse-deadline-context branch from c9d8ebc to 05c1acd Compare May 22, 2019 19:52
@vyzo
Copy link
Contributor Author

vyzo commented May 22, 2019

what the hell happened to travis?

@Stebalien
Copy link
Member

travis

Needs to be enabled here: https://travis-ci.org/organizations/libp2p/repositories. I don't have permissions.

deadlines

Could we try using https://github.com/libp2p/go-yamux/blob/master/deadline.go like we do in yamux? Then, we can just drop the contexts.

@vyzo
Copy link
Contributor Author

vyzo commented May 22, 2019

Could we try using https://github.com/libp2p/go-yamux/blob/master/deadline.go like we do in yamux? Then, we can just drop the contexts.

ah yes, that might be good.

@vyzo
Copy link
Contributor Author

vyzo commented May 22, 2019

Modified to use the pipeDeadline thingie.

@vyzo vyzo changed the title reuse deadline contexts don't use contexts for deadlines May 22, 2019
multiplex.go Outdated
case <-ctx.Done():
return ctx.Err()
case <-done:
return errors.New("invalid context")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

? Shouldn't this be a timeout error?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, good point. Is there an existing error we can reuse?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not that I know of. We just need an error that returns true for both Timeout() bool and Temporary() bool.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I made an errTimeout, perhaps we want to export this (or reuse an existing error if applicable)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, we need the Timeout and Temporary methods too, let me add.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@@ -410,6 +412,8 @@ func (mp *Multiplex) handleIncoming() {

msch.clLock.Unlock()

msch.cancelDeadlines()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to encapsulate this more... but we can handle that later.

defer s.deadlineLock.Unlock()
s.rDeadline = t
s.wDeadline = t
s.rDeadline.set(t)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should try to prevent this from happening after closing the stream so we don't leak a timer. Not that much of an issue but is there some kind of state lock we can take?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could try the clLock and check if it has been closed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I used the clLock and return an error if the stream has been closed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@vyzo vyzo requested a review from Stebalien May 22, 2019 20:47
defer s.deadlineLock.Unlock()
s.rDeadline = t
s.wDeadline = t
s.rDeadline.set(t)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

stream.go Outdated
case <-ctx.Done():
return ctx.Err()
case <-s.rDeadline.wait():
return context.DeadlineExceeded
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably return a timeout error instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point, will do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

multiplex.go Outdated
type timeout struct{}

func (_ timeout) Error() string {
return "timeout"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"i/o deadline exceeded"? (or one for read/write?)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, that's better. will do.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

stream.go Outdated
s.clLock.Lock()
defer s.clLock.Unlock()

if s.closedRemote && s.isClosed() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should probably be an or, will fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, this should probably be two cases. We want to be able to set a write deadline even when closed for reading and vice versa.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be inconsistent to set one of the two deadlines I think.

@vyzo vyzo merged commit d70f09a into master May 22, 2019
@Stebalien Stebalien deleted the fix/reuse-deadline-context branch May 22, 2019 21:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants