There are two servers A and B, they use A GRPC long link to interact, A is GRPC server, in public; In Intranet, B is the client, the server code in A has two collaborators, to monitor the HTTP and GRPC respectively, with A synchronized channel for communication,

My business processes: 1, the user through the HTTP interface to access A, A need to call B program, this time using the Send error Response (*) the necessary parameter to Send in the past; 2, B through Recv () to ask for instructions from A monitoring, the operation result through the Send () is sent back to A; 3, A through Recv () received operation results, enter the results into synchronous channel, synchronous blocking the end of the HTTP service returns the HTTP response to the user,

Now I want to be in step 1 with 30 seconds of overtime restrictions, but appeared strange questions, pseudo code is as follows:

 
A.S end (" data... 
 ")
Go func () {
Time. Sleep (30 e9) 
TimeoutChan & lt; - true 
} () 

The select {
Case & lt; - timeoutChan: 
//return the timeout error message 
Case resp:=& lt; - respChan: 
//normal return data 
} 

According to my idea, should be A user to access A HTTP interface, if more than 30 seconds, will get A timeout error, but the following problems, have A concurrent for instructions (assuming that just asking 1 and 2) instruct, asking 1 to get the result of the HTTP response is asking 2, asking 2 to get the HTTP response is the result of asking 1,

I rolled back to the original code, (that is, remove the timeout limit function, without the above go func () {time. Sleep ()} and the select... Case... ), only use the synchronization channel block waiting for the results returned, to conduct stress tests, will not be out on the above problem, can correspond to the HTTP request and response, so now think impassability, why the select... Case... Will appear the above question, what do I need to improve,

CodePudding user response:

Your chanel is a global variables or local variables? Multi-threaded Shared variables should pay attention to synchronization,
Your code is not complete, speculation is the chanel are Shared variables, request 1 and 2 main thread is blocked in the select, but respChan is Shared, request 1 processing coroutines to send results respChan channel, after the requested 2 in the select got the first, the request is returned in the response of the request 1, 2, same request 2 after the processing of coroutines to send results respChan channel, 1 got the requested, the request 1 is returned in the response of the request 2, ie, multithreading, rrspChan Shared variables synchronous not ready,