🚀 go-pugleaf

In article <JAD.92Oct28104214@pimlico.nsa.hp.com> jad@nsa.hp.com (John Dilley) writes:
>In article <5429@bacon.IMSI.COM> jordan@IMSI.COM (Jordan Hayes) writes:
>> That's exactly what needs to be preserved.  Consider the two types of
>> requests TellMeAbout and StopTellingMeAbout ... if the
>> StopTellingMeAbout message shows up before the TellMeAbout in a quick
>> transaction, what happens?
>
>	In the synchronous (DCE RPC) model I would have created a single
>thread that calls TellMeAbout some number of times, blocking to await
>the reply to each, then called StopTellingMeAbout prior to exiting the
>thread.  As you and rcbc@honir.cs.cornell.edu (Robert Cooper) correctly
>point out, this will cause my thread to block awaiting each reply from
>the server.  I agree that an asynchronous, sequenced communication
>system could significantly improve the efficiency of this call sequence.

Actually, with DCE RPCs you could specify the "maybe" attribute for 
TellMeAbout and StopTellingMeAbout, which requires that your RPC returns
no data. DCE doesn't guarantee that "maybe" RPCs are delivered, but it
presumably doesn't wait for a response either. This would be a better
way to implement such asynchronous communication if you're willing to
check that the message got received on your own, or if you don't care if
the message gets received.

				greg
-- 
Greg Brail ------------------ Citibank -------------------- gjb@fig.citib.com
lose (lOOz) v. 1. a. To be unable to find; mislay. b. To incur the 
deprivation of, as by negligence or accident. 2. To be unable to maintain,
sustain, or keep. 3. The most commonly misspelled word on Usenet.