[Xcb] GTK-XCB is in progress
Barton C Massey
bart at cs.pdx.edu
Wed Nov 8 18:42:27 PST 2006
Yep. Someone should mark up the wiki accordingly.
Bart
In message <934b4cdf0611081815t5152ad15wfcabba06f1d5a0a3 at mail.gmail.com> you wrote:
> ------=_Part_28052_16582877.1163038548434
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> your "force the returned cookie" means asking for a reply with the returned
> cookie, right?
>
> On 11/8/06, Barton C Massey <bart at cs.pdx.edu> wrote:
> >
> > The general ruleset I always intended for using a cookie to
> > hide latency is this:
> > 1. Always send a request as soon as you legally can.
> > 2. Never force the returned cookie until you actually need
> > to examine the result.
> > In the presence of multiple requests, it gets a bit more
> > complicated.
> > 1. Always send each request as soon as you legally can.
> > 1a. If you can send multiple requests at the same time,
> > send the one whose value you expect to need first,
> > first.
> > 1b. If rule 1a doesn't help, a secondary tiebreaker
> > is that it's better to send requests the server
> > can process quickly first, followed by those
> > the server might run slowly.
> > 2. Never force a returned cookie until you actually need
> > to examine the result.
> >
> > The idea of rule 1b is that if you're lucky, you can be
> > working on the quick results while the server is processing
> > the slow request. In general, don't worry about ordering of
> > simultaneous requests too much. It's hard to construct a
> > realistic example where these kinds of corner cases matter.
> >
> > Note that rule 2 is stronger than necessary in the presence
> > of multiple requests. If you need to force a cookie returned
> > for a request r, it is harmless to also force cookies
> > returned from requests earlier than r: these values will be
> > available anyway, since the server always returns results in
> > order. However, it is also harmless to wait to force a
> > cookie until you need the value, and it makes it clearer
> > that you've done the right thing.
> >
> > If you follow these rules, you will be getting about all the
> > latency hiding you can expect from what is a fundamentally
> > serialized protocol without using threading or some
> > equivalent mechanism.
> >
> > Hope this helps. Comment welcome.
> >
> > Bart
> >
>
> ------=_Part_28052_16582877.1163038548434
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> your "force the returned cookie" means asking for a reply with the returned cookie, right?<br><br><div><span class="gmail_quote">On 11/8/06, <b class="gmail_sendername">Barton C Massey</b> <<a href="mailto:bart at cs.pdx.edu">
> bart at cs.pdx.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The general ruleset I always intended for using a cookie to
> <br>hide latency is this:<br> 1. Always send a request as soon as you legally can.<br> 2. Never force the returned cookie until you actually need<br> to examine the result.<br>In the presence of multiple requests, it gets a bit more
> <br>complicated.<br> 1. Always send each request as soon as you legally can.<br> 1a. If you can send multiple requests at the same time,<br> send the one whose value you expect to need first,<br> first.
> <br> 1b. If rule 1a doesn't help, a secondary tiebreaker<br> is that it's better to send requests the server<br> can process quickly first, followed by those<br> the server might run slowly.
> <br> 2. Never force a returned cookie until you actually need<br> to examine the result.<br><br>The idea of rule 1b is that if you're lucky, you can be<br>working on the quick results while the server is processing<br>
> the slow request. In general, don't worry about ordering of<br>simultaneous requests too much. It's hard to construct a<br>realistic example where these kinds of corner cases matter.<br><br>Note that rule 2 is stronger than necessary in the presence
> <br>of multiple requests. If you need to force a cookie returned<br>for a request r, it is harmless to also force cookies<br>returned from requests earlier than r: these values will be<br>available anyway, since the server always returns results in
> <br>order. However, it is also harmless to wait to force a<br>cookie until you need the value, and it makes it clearer<br>that you've done the right thing.<br><br>If you follow these rules, you will be getting about all the
> <br>latency hiding you can expect from what is a fundamentally<br>serialized protocol without using threading or some<br>equivalent mechanism.<br><br>Hope this helps. Comment welcome.<br><br> Bart<br></blockquote>
> </div><br>
>
> ------=_Part_28052_16582877.1163038548434--
More information about the Xcb
mailing list