-
-
Notifications
You must be signed in to change notification settings - Fork 111
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
Fix RPC deadlock #196
Conversation
There was a problem hiding this 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.
|
||
var cherrPool = make(errChanPool, 64) | ||
|
||
type errChanPool chan errChan |
There was a problem hiding this comment.
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)) |
There was a problem hiding this comment.
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 unsafe
is 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 } |
There was a problem hiding this comment.
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.
I think it's going to be easier to start again from scratch. Closing. |
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.