To answer the "why did we do this?" question from earlier -- sequence ids were added so that we could add this functionality in the future (non-sequential or parallel request processing). So far, we haven't added it, mainly because it hasn't been a huge pain-point or need.
However, there's no philosophical opposition to changing or parallilizing the order of request processing. If we do this, the sequence ids will come in handy (my initial thoughts around this were that the client would hold a map of sequence id => continuation objects, and a parallized server would just have one multiplexer that sits in front of the workers and owns the transports -- making sure response bytes don't get randomly interleaved). mcslee -----Original Message----- From: Todd Lipcon [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2008 10:45 AM To: [email protected] Subject: Re: Semantics of asynchronous calls On Fri, 5 Sep 2008, David Reiss wrote: > I'm pretty sure all of the current implementations (with the possible > exception of Erlang) will processes them in order. I'm not sure > whether we should make this a defined behavior, but I'm leaning toward "no". Erlang has the same behavior as the other languages in this respect - we decided that if you want async calls to be processed in parallel this should be done at the service level, not at the binding level. -Todd
