hello to you all. Let me describe my cenario... I have my L4 server that receives ipc calls. The code was generated from DICE. And i have a lib and i've implemented a client that uses that lib. My L4 server also uses ipc to comunicate with other servers, mainly with flips that also uses IPC. that problem is the following: My client makes an IPC call and blocks waiting for the answer from my server... while processing that answer, my server has to comunicate with flips using IPC. The problem is here... my server blocks in the ipc_send when calling flips, but when i remove the call from the client it works fine, meaning that the client is not blocked waiting for ipc to return. My questions are... why can't i do IPC while another one that has nothing to do with my server is blocked? there can be only one ipc call in the whole system at a time? they all must be sequential? thanks in advance Tiago
I will try to describe the scenario as I understood it: There exist: - The Flips Server (F) - The Server (S) with one server thread - One or more Clients (C1, C2, ...). Now C1 calls S, which receives the message, decodes it, calls your server function, makes a call to F and blocks, waiting for the reply from F. The C2 tries to call the same server S. If this is correct, then yes, C2 and all following clients will block, because the server-thread is blocked waiting for F. To solve this, you would have to build a multithreaded server S. Greetings, Ron. Tiago Jorge wrote on 05/02/05 14:52 this:
hello to you all. Let me describe my cenario... I have my L4 server that receives ipc calls. The code was generated from DICE. And i have a lib and i've implemented a client that uses that lib. My L4 server also uses ipc to comunicate with other servers, mainly with flips that also uses IPC. that problem is the following: My client makes an IPC call and blocks waiting for the answer from my server... while processing that answer, my server has to comunicate with flips using IPC. The problem is here... my server blocks in the ipc_send when calling flips, but when i remove the call from the client it works fine, meaning that the client is not blocked waiting for ipc to return. My questions are... why can't i do IPC while another one that has nothing to do with my server is blocked? there can be only one ipc call in the whole system at a time? they all must be sequential?
thanks in advance
Tiago
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
-- Mit freundlichen Gruessen / with regards ra3 @ inf.tu-dresden.de http://os.inf.tu-dresden.de/~ra3/
[Tiago Jorge]
The problem is here... my server blocks in the ipc_send when calling flips, but when i remove the call from the client it works fine, meaning that the client is not blocked waiting for ipc to return. My questions are... why can't i do IPC while another one that has nothing to do with my server is blocked? there can be only one ipc call in the whole system at a time? they all must be sequential?
[Ronald Aigner]
I will try to describe the scenario as I understood it: There exist: - The Flips Server (F) - The Server (S) with one server thread - One or more Clients (C1, C2, ...).
Now C1 calls S, which receives the message, decodes it, calls your server function, makes a call to F and blocks, waiting for the reply from F. The C2 tries to call the same server S.
If this is correct, then yes, C2 and all following clients will block, because the server-thread is blocked waiting for F.
I believe the problem was that S blocks (in the send part) when calling F, but only when a client is waiting for a reply from S. eSk
Espen Skoglund wrote:
[Tiago Jorge]
The problem is here... my server blocks in the ipc_send when calling flips, but when i remove the call from the client it works fine, meaning that the client is not blocked waiting for ipc to return. My questions are... why can't i do IPC while another one that has nothing to do with my server is blocked? there can be only one ipc call in the whole system at a time? they all must be sequential?
[Ronald Aigner]
I will try to describe the scenario as I understood it: There exist: - The Flips Server (F) - The Server (S) with one server thread - One or more Clients (C1, C2, ...).
Now C1 calls S, which receives the message, decodes it, calls your server function, makes a call to F and blocks, waiting for the reply from F. The C2 tries to call the same server S.
If this is correct, then yes, C2 and all following clients will block, because the server-thread is blocked waiting for F.
I believe the problem was that S blocks (in the send part) when calling F, but only when a client is waiting for a reply from S.
eSk
thats true :) Tiago
Ronald Aigner wrote:
I will try to describe the scenario as I understood it: There exist: - The Flips Server (F) - The Server (S) with one server thread - One or more Clients (C1, C2, ...).
Now C1 calls S, which receives the message, decodes it, calls your server function, makes a call to F and blocks, waiting for the reply from F. The C2 tries to call the same server S.
If this is correct, then yes, C2 and all following clients will block, because the server-thread is blocked waiting for F.
nop. the problem is that S blocks when doing the call to F with no reason. But when i removed the call from C1 to S (that is blocked waiting the IPC response from S), S did the F IPC with no problem... So it is S that is blocked when doing the ipc_send call to F, not waiting for the answer, because the request never arrives to the F server. thanks Tiago
Tiago Jorge wrote on 05/02/05 15:37 this: >>I will try to describe the scenario as I understood it: >>There exist: >>- The Flips Server (F) >>- The Server (S) with one server thread >>- One or more Clients (C1, C2, ...). >> >>Now C1 calls S, which receives the message, decodes it, calls your >>server function, makes a call to F and blocks, waiting for the reply >>from F. The C2 tries to call the same server S. >> >>If this is correct, then yes, C2 and all following clients will block, >>because the server-thread is blocked waiting for F. >> > > nop. > the problem is that S blocks when doing the call to F with no reason. > But when i removed the call from C1 to S (that is blocked waiting the > IPC response from S), S did the F IPC with no problem... So it is S that > is blocked when doing the ipc_send call to F, not waiting for the > answer, because the request never arrives to the F server. So, the non-blocking szenario is: - no client does send any message to S. - S (magically*) sends a message to F and receives a reply (**) * how is this request initiated if not by a client? ** let us try to stay with the L4 speech: - an "IPC send" is an IPC from thread T1 to T2 without an immediate reply - an "IPC call" is an IPC from thread T1 to T2 and T1 atomically waits for a reply from T2 (i.e. is blocked until T2 sends the reply). - so, if you remove "the ipc_send call to F" what do you mean in L4 speech? And the blocking szenario is: - C1 calls S. - S calls F, but blocks in the send phase of the call. Did I get it right now? (The respective code snippets or IDL would be helpful.) Greetings, Ron. -- Mit freundlichen Gruessen / with regards ra3 @ inf.tu-dresden.de http://os.inf.tu-dresden.de/~ra3/
Ronald Aigner wrote:
Tiago Jorge wrote on 05/02/05 15:37 this:
I will try to describe the scenario as I understood it: There exist: - The Flips Server (F) - The Server (S) with one server thread - One or more Clients (C1, C2, ...).
Now C1 calls S, which receives the message, decodes it, calls your server function, makes a call to F and blocks, waiting for the reply
from F. The C2 tries to call the same server S.
If this is correct, then yes, C2 and all following clients will block, because the server-thread is blocked waiting for F.
nop. the problem is that S blocks when doing the call to F with no reason. But when i removed the call from C1 to S (that is blocked waiting the IPC response from S), S did the F IPC with no problem... So it is S that is blocked when doing the ipc_send call to F, not waiting for the answer, because the request never arrives to the F server.
I like your description :)
So, the non-blocking szenario is: - no client does send any message to S. - S (magically*) sends a message to F and receives a reply (**)
* how is this request initiated if not by a client? ** let us try to stay with the L4 speech: - an "IPC send" is an IPC from thread T1 to T2 without an immediate reply - an "IPC call" is an IPC from thread T1 to T2 and T1 atomically waits for a reply from T2 (i.e. is blocked until T2 sends the reply). - so, if you remove "the ipc_send call to F" what do you mean in L4 speech?
The imaginary test cenario was the following... i've removed the client and i've emulated internally the call so i could test if the problem was from the comunication S<->F... so the only ipc here its between S and F :). I've never removed the call from F. Only from C1. I must always have network.
And the blocking szenario is: - C1 calls S. - S calls F, but blocks in the send phase of the call.
Did I get it right now? (The respective code snippets or IDL would be helpful.)
yep... thats the problem. if i use the emulated szenario explained above, the ipc between S<->F works... if i put the client the S<->F does not work...:( my doubt remains... why can't i do the second IPC? because i've debugged the client stubs and the server-side stubs and i've realized that S blocks in the ipc_send, the call never arrives on the server... Tiago
Tiago Jorge wrote on 05/02/05 17:13 this: <snip>
And the blocking szenario is: - C1 calls S. - S calls F, but blocks in the send phase of the call.
Did I get it right now? (The respective code snippets or IDL would be helpful.)
yep... thats the problem.
if i use the emulated szenario explained above, the ipc between S<->F works... if i put the client the S<->F does not work...:( my doubt remains... why can't i do the second IPC? because i've debugged the client stubs and the server-side stubs and i've realized that S blocks in the ipc_send, the call never arrives on the server... Ok. understood it now ;) To answer your original question: Of course there may be multiple IPCs in progress at one moment in time.
But to solve your problem wh S blocks, sources would be helpful. Greetings, Ron. -- Mit freundlichen Gruessen / with regards ra3 @ inf.tu-dresden.de http://os.inf.tu-dresden.de/~ra3/
Tiago Jorge(tjpj@lasige.di.fc.ul.pt)@2005.05.02 16:13:53 +0000:
Ronald Aigner wrote:
And the blocking szenario is: - C1 calls S. - S calls F, but blocks in the send phase of the call.
Did I get it right now? (The respective code snippets or IDL would be helpful.)
yep... thats the problem.
if i use the emulated szenario explained above, the ipc between S<->F works... if i put the client the S<->F does not work...:( my doubt remains... why can't i do the second IPC? because i've debugged the client stubs and the server-side stubs and i've realized that S blocks in the ipc_send, the call never arrives on the server... Then i would say, F is simply not in open wait or in closed wait for S. Maybe F is blocked, because it handles an another request. If you use fiasco, i assume this, then simply check the state from F. It should be in Thread_receiving|Thread_ipc_in_progress (the Thread_ready bit doesnt hurt to). The ipc partner should be * for open wait or S.
rene
participants (4)
-
Espen Skoglund -
Rene Reusner -
Ronald Aigner -
Tiago Jorge