Richard Stallman <[EMAIL PROTECTED]> writes:

> I suspect this measurement will be meaningless when using the net,
> because it would only tell you how long it took to write all the
> output into some buffer in the ethernet driver.  You won't even know
> when it is sent out on the ethernet.

But then the existing pre-emption check is also meaningless, since
redisplay (due to output buffering) will usually complete before more
input arrives.

> It's possible that your suggestion will give good results nonetheless.

At least, I don't think it will be any worse ... and btw, it also
adapts pre-emption to the actual cpu load on the local systems.

> Pre-emption probably doesn't work very well with added latency of an
> internet connection, especially given all the buffering.  (The Supdup
> protocol, which I worked on in 1980 or so, limited the amount of
> buffering so that pre-emption of Emacs redisplay would work better.)
> Usually the whole screenful will get buffered anyway.

Does the X protocol buffer requests like that?  Last time I looked,
it didn't do much buffering before transmitting on the wire.  But
IIRC, there may be some X-aware protocol which does buffering.

> So please install your patch, and document it.  Then we can see
> how well it works.

I'll do that.

-- 
Kim F. Storm <[EMAIL PROTECTED]> http://www.cua.dk



_______________________________________________
emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug

Reply via email to