Hi,
I implemented an IDL with a allow_reply_only method : start. When client calls this, it is blocked until server decides to send reply. This works fine in general. But when client thread disapears after call, I cannot get error code from reply function on server side. I tried to use error_function, but it is not called. Is there another way to get this info ?
Regards Marc
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marc Chaland wrote on 03/12/2008 09:23 PM this:
Hi,
I implemented an IDL with a allow_reply_only method : start. When client calls this, it is blocked until server decides to send reply. This works fine in general. But when client thread disapears after call, I cannot get error code from reply function on server side. I tried to use error_function, but it is not called. Is there another way to get this info ?
When you add the error_function_server attribute to the respective interface, does the generated code for the reply function contain code that looks something like this?
if (DICE_EXPECT_FALSE(DICE_IPC_ERROR(_dice_result))) name_of_error_function(_dice_result, _dice_corba_env);
Then, you might want to check if the IPC returns at all (i.e., the reply function returns). Please send your findings, so we know what steps to check next.
Sincerely, Ron. - -- Mit freundlichen Gruessen / with regards ra3 @ inf.tu-dresden.de http://os.inf.tu-dresden.de/~ra3/
From Ronald Aigner:
When you add the error_function_server attribute to the respective interface, does the generated code for the reply function contain code that looks something like this?
OK, I've tried to put this on an inherited interface. If I put it on the right interface, it's fine :).
However, into error_function, I don't know how to get info on destination thread and call which generated error. Before reply call, I set a global variable to 0. error_function sets it to 1 if it is called. After reply call, I check this variable. If set to 1, I consider destination thread dead. Is there another way to do this less trickly ?
Regards Marc
Marc Chaland wrote on 03/13/2008 04:59 PM this:
From Ronald Aigner:
When you add the error_function_server attribute to the respective interface, does the generated code for the reply function contain code that looks something like this?
OK, I've tried to put this on an inherited interface. If I put it on the right interface, it's fine :).
However, into error_function, I don't know how to get info on destination thread and call which generated error. Before reply call, I set a global variable to 0. error_function sets it to 1 if it is called. After reply call, I check this variable. If set to 1, I consider destination thread dead. Is there another way to do this less trickly ?
Before calling the reply function you could set the partner member of the CORBA_Server_Environment parameter. This environment is passed to the error function. In the error function you could then check the partner member.
Or, there is a user_data member in the CORBA_Server_Environment, which is of type void*. You could let it point to whatever data you need in the error function.
Regards, Ron.
From Ronald Aigner:
Before calling the reply function you could set the partner member of the CORBA_Server_Environment parameter. This environment is passed to the error function. In the error function you could then check the partner member.
Is it a good idea to use CORBA_server_exception_set into error_function and manage error after reply function call ? Should I call some ipc error cleanup after ?
Regards Marc
Marc Chaland wrote on 03/13/2008 06:32 PM this:
From Ronald Aigner:
Before calling the reply function you could set the partner member of the CORBA_Server_Environment parameter. This environment is passed to the error function. In the error function you could then check the partner member.
Is it a good idea to use CORBA_server_exception_set into error_function and manage error after reply function call ? Should I call some ipc error cleanup after ?
Yes, you could do that. All you have to do when handling the error is call CORBA_server_exception_free. Check the implementation of these functions (dice/include/dice.h) to see which members of the CORBA_Server_Environment are set and cleared (to avoid interference with other surrounding Dice generated code).
Regards, Ron.
l4-hackers@os.inf.tu-dresden.de