[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference tuxedo::dce-products

Title:DCE Product Information
Notice:Kit Info - See 2.*-4.*
Moderator:TUXEDO::MAZZAFERRO
Created:Fri Jun 26 1992
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2269
Total number of notes:10003

2249.0. "RPC without blocking client [maybe?]" by AWECIM::KING () Wed May 14 1997 16:43

  I am trying to figure a way to activate a remote procedure that does not 
  require the client to be blocked until the server returns.  What I'm 
  looking for is something equivalent to a "one-way" in the ORB world or an
  event notification in the MOM realm.

  I tried using the "maybe" procedure qualifier which says that the caller 
  neither expects nor waits for a return.  In using this with Microsoft RPC
  connected to a DCE server (v1.3) on a VAX, the client ended up waiting anyway. 
  I read in another note in this conference that that's not wrong. That is, it's
  legal in DCE land to convert idempotent to non-idempotent if the run-time 
  wants to do so..

  My question...is there a way to force control to always return to the 
  client after activating a specific remote procedure?  For this particular 
  service I never want to wait for the server to finish processing the client 
  request.

  Thanks for your help...

  Jim
T.RTitleUserPersonal
Name		DateLines
2249.1create a threadFOUNDR::WOODRUFFWed May 14 1997 16:585
 you could make the RPC call in a separate thread assuming your client stays
 running.

garry
2249.2application is thread intolerantAWECIM::KINGWed May 14 1997 18:247
  I forgot to mention in .0 that the application is thread intolerant.  That's 
  why I'm looking for a way to make the remote procedure call return immediately
  without holding up the client from its other obligations.

  Any further ideas are appreciated...thanks,

  Jim
2249.3TUXEDO::WRAYJohn Wray, Distributed Processing EngineeringThu May 15 1997 14:2216
>  I forgot to mention in .0 that the application is thread intolerant.  That's 
>  why I'm looking for a way to make the remote procedure call return immediately
>  without holding up the client from its other obligations.
    
    I'm not sure what you mean by "thread intolerant", but you should be
    aware that applications that link against DCE are in general executing
    in a multi-threading environment;  whether or not the application
    explicitly creates any threads, the DCE runtime may choose to create
    threads of its own.
    
    Therefore, perhaps the use of an application-created thread for this
    purpose is permissible - the thread could be created to make the RPC
    and then terminate.  If that's all this thread does, non-reentrant code
    elsewhere in the application shouldn't be a problem.
    
    John
2249.4Maybe a fire-and-forget thread is what I needAWECIM::KINGFri May 16 1997 09:3911
  re .3: That's a good point John.  I was concerned that use of threads anywhere
  in a program could have adverse effects on the non-reentrant code in the rest 
  of the program.  I had ignored the possibility that an application that uses 
  DCE might employ threads somewhere under the covers.  

  As suggested in previous notes, I will try a "fire-and-forget" thread to 
  produce the equivalent asynchronous behavior.

  Thanks for the advice...

  Jim