Christian Ohler <[EMAIL PROTECTED]> writes: >> So a filter function would be completely unnecessary. > > But what is the advantage of polling for input every 0.3s? There's > still no guarantee that a complete line or stanza (or any input > whatsoever) will have arrived.
The advantage of polling every 0.3s has nothing to do with whether the
stanza is complete -- I addressed this in my initial email as follows:
- It should be smart about determining whether a complete entry is
present in the buffer. One way of doing this is to move to the
process mark, re-search-backward by one start delimiter, and only
look at the output between the former value of process mark and
point.
The advantage of polling is that we get to process larger chunks of data
at once, compared to a filter function. Emacs 22 allows us to somewhat
alleviate that (though in a not very fine-grained manner) by setting
process-adaptive-read-buffering to non-nil. The problem is that XEmacs
does not have this function. And this only waits a maximum of 50
milliseconds, which is not even close to how long I'd prefer to wait
between polls.
> On a slow machine or under very high load, git may have to wait for
> I/O for several seconds, so activating Emacs to look for new input
> every 0.3s would be way too often. On a fast dual-core machine, a
> delay of 0.3s before beginning parsing is redundant since it would
> just leave one of the cores idle and the user waiting.
This argument doesn't make sense to me. By using run-at-time, the log
parser cedes control back to the user until the next poll attempt. So
one of the cores would most definitely not be idle.
> A process filter function avoids this problem since it lets the
> operating system scheduler decide at what intervals Emacs should be
> activated. That is what these mechanisms are for. A solution based
> on process filter functions will also be simpler to implement, since
> there will be no need to manage timers.
Timers really are simple in Emacs Lisp, especially run-once timers. The
log parser gets to choose whether to activate itself again in the
future, which might even allow us to do fancy things like poll every
0.1s, up to 1 second, then 0.3s up to 10 seconds, and then every 1s
thereafter until the process terminates.
--
Michael Olson -- FSF Associate Member #652 |
http://mwolson.org/ -- Jabber: mwolson_at_hcoop.net | /` |\ | | |
Sysadmin -- Hobbies: Lisp, GP2X, HCoop | |_] | \| |_|
Projects: Emacs, Muse, ERC, EMMS, ErBot, DVC, Planner |
pgpMHUTumxeoK.pgp
Description: PGP signature
_______________________________________________ Dvc-dev mailing list [email protected] https://mail.gna.org/listinfo/dvc-dev
