>>>> "kkm" == Kirill 'Big K' Katsnelson
<kkm(a)dtmx.com> writes:
kkm> Some time ago, Stephen J. Turnbull wrote...
> I don't understand; the check at l. 6457 looks OK. Comment
in
> redisplay_frame() indicates this is intentional. Or do you
> just mean all frames on the current device? That's bad enough
> to justify this patch, though.
kkm> Stephen, what comment are you referring to?
There's a comment at line 6281
if (preemption_check)
{
/* The preemption check itself takes a lot of time,
so normally don't do it here. We do it if called
from Lisp, though (`redisplay-frame'). */
int preempted;
REDISPLAY_PREEMPTION_CHECK;
if (preempted)
return 1;
}
An identical check is done in redisplay_device() at l 6457, basically
the first thing that redisplay_device() does:
REDISPLAY_PREEMPTION_CHECK;
if (preempted)
return 1;
kkm> I may have modified the file, so line numbers are off.
The lines in your patch were exact, so I assumed redisplay.c is the
same in 21.4.3 and 21.5 (the above excerpts are from 21.4.3).
kkm> because there was obvious nonsense in the above lines:
As I say, it appears to be intentional. A misjudgement, I think after
light testing, but intentional.
kkm> r_f() never gets preempted, and thus never returns non-zero when
kkm> its second parameter equal 0.
kkm> That is, preemption never happened! CVS revision 1.1.1.1,
kkm> the oldest one, also has the preemption check turned off.
AFAICT it happens once per call of redisplay_device().
> Maybe you should post patches of this type to xemacs-beta?
kkm> What I meant by testing was that I wanted everybody to keep
kkm> an eye open on glitches in display appearance.
Oh I understood that. What I meant is that "count(everybody)" is a
lot bigger on xemacs-beta. Everybody on xemacs-beta (pretty much) can
read patches; with that and the description they can probably give it
a lot more thorough workout than the few on xemacs-review.
Especially with the commit-for-review policy, it's important to keep
the testers aware of changes where the developers don't fully
understand the consequences.
kkm> Thank you for checking it, in any case!
I'm in swap now, and VM still seems faster. :-) I like this patch, a
lot!
--
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091
_________________ _________________ _________________ _________________
What are those straight lines for? "XEmacs rules."