Jeffrey Altman wrote: > Kevin Koch wrote: >> Thanks for that suggestion. I don't believe the local RPC mechanism uses >> TCP or UDP so are I/O completion ports applicable? > I'm sorry I haven't had time to provide a detailed response to your > question. The choice of which RPC mechanism is used is up to you. > Either TCP or Named Pipes can be used instead of local rpc if you want > to establish a connection between the two processes that can provide for > endpoint connectivity detection. > Both of these methods are frowned upon because they require the > allocation of additional kernel resources. > > Another approach that is much lower cost would be to use the client to > server connection to communicate the name of a global object that is > allocated by the client. The client can lock the object and the server > can add the object to a list of objects it waits on (or tests at the > beginning of each incoming request.) If the client dies, the server > will be able to lock the object or will detect that the object is no > longer present. This approach takes advantage of the shared resources > of the local system and does not require the use of heavy weight RPC > mechanisms. > > Jeffrey Altman Better idea, get a handle to the client process and wait on that.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ kfwdev mailing list kfwdev@mit.edu http://mailman.mit.edu/mailman/listinfo/kfwdev
