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

Fix RPC deadlock #196

Closed
wants to merge 5 commits into from
Closed

Fix RPC deadlock #196

wants to merge 5 commits into from

Conversation

lthibault
Copy link
Collaborator

Fixes #190 and #194.

@zenhack This is still WIP, but I want to get some early feedback. Can you look over this and make sure I'm on the right track? Thanks.

Copy link
Contributor

@zenhack zenhack left a comment

Choose a reason for hiding this comment

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

This seems like it is broadly on the right track, though some parts I have only skimmed. A few things mentioned in-line.

rpc/rpc.go Outdated Show resolved Hide resolved

var cherrPool = make(errChanPool, 64)

type errChanPool chan errChan
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't really understand why this was introduced? What is this doing for you?

return sendFailure(err)
}

return *(*preparer)(unsafe.Pointer(&v))
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this is correct; the inserted value is a sendReq, and I'm not sure the memory layout will be the same as if it is passed in as a preparer.

You should probably just use a type assertion here anyway:

v.(sendReq)

...I do not think unsafeis warranted here.

func (prepare prepFunc) Prepare(m rpccp.Message) error { return prepare(m) }

func sendFailure(err error) prepFunc {
return func(rpccp.Message) error { return err }
Copy link
Contributor

Choose a reason for hiding this comment

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

There is a lot of indirection in this file that as far as I can tell only serves to simplify the body of Conn.send. But my feeling is it would probably be better to have some if/elses in there than to do it this way; this seems very convoluted.

@lthibault
Copy link
Collaborator Author

I think it's going to be easier to start again from scratch. Closing.

@lthibault lthibault closed this Feb 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Possible deadlock when receive loops on both sides of an unbuffered connection try to send.
2 participants