Conference tuxedo::dce-products

2218.0. "pthread_cancel question" by BRSVMS::VDKERCKHOVE (Eric Vandekerckhove) Fri Apr 11 1997 11:28

Hi,

Suppose I have a DCE client application that has to poll 2 different DCE
servers for information at regular intervals by issuing an RPC (pollRPC).  Also
suppose that this pollRPC cannot take longer than a limited time, so the
pollRPC needs to be timed.

So, the pollRPC is placed in a TRY/CATCH block and before the actual poll RPC 
is done, a timer thread is created. If the pollRPC is completed in-time, the
timer thread is cancelled and exits. If the timer thread returns from its
pthread_delay routine, it pthread_cancels its father, who is still in his
pollRPC. The cancel is CATCHed and the loop continues. The problem in this case
is that the next pollRPC (to the other server which is still running correctly)
also returns with an error (rpc_s_cancel_timeout) and the main loop coredumps
in the  pthread_delay_np with Exception: Thread has been canceled (dce / thd).

        o
  +---->|
  |     +----->+
  |     |      |
  |     |      |
  |     |    sleep
  | pollRPC<-cancel
  |     |
  |     +------>+
  | nextpollRPC |
  |   cancel--->sleep
  |     |
  |   sleep(pthread_delay)
  |     |
  ------+

I have 2 questions here:

1. Is pthread_cancel doing more than just delivering a signal, so that
   subsequent rpc and pthread_delay calls in the cancelled thread crash ?

2. Is there an alternative to achieve timed rpc's other than to run the pollRPC
   in a thread of its own ?

Thanks in advance
Eric.

Eric,

I did some tests for a customer and it actually worked. Although we had
some problems in using authenticated RPCs. Maybe you're doing something
special with the cancelled RPC. Can you post the critical part of the source ?
(pthread_join, pthread_detach ???)

As I understand the cancel delivers a message to the server to stop this
RPC. There is some additional work to do if it's an authenticated RPC.

I also tried a different approach: The client started a RPC. The RPC has
a time parameter. The server receives the RPC and registers with a kill-
procedure with the time parameter. The rest of the work is done in a
separate thread on the server side. If the time frame expires the work
thread gets killed and the server returns an appropriate return value.
This approach worked fine and is (my oppinion) better for a three-tier
architecture.

Hope this helps

Marco
 
[Posted by WWW Notes gateway]

I'll post a summary in the end of this call

/marco

Sorry but I do not undertand the comment of Bill ( Last name)

Please, if anyone has a good way to implement a timeout in an RPC call, inform
use


Regards,


Christian
[Posted by WWW Notes gateway]