Re: crash
At 08:38 PM 3/7/00 +0900, Stephen J. Turnbull wrote:
Changing the configuration of buffers does not involve
reinstantiation
of the tabs?
Not generally, because the specifiers are instantiated on a frame and
window basis. If you don't change any windows (selecting a different buffer
doesn't count) then you don't change any specifiers and therefore do not
get any instantiation.
I guess technically you might be right in the sense that
a new tab widget won't be allocated, but there is going to be a
complex relationship between Lisp computations and the redisplay
mechanism, and caches are going to get invalidated. I thought that
was where the problem comes in?
I thought there were two problems:
a) Calling lisp code in redisplay will generally make redisplay slow. This
used to happen as an integral part of redisplay I believe (calling lisp and
the slowness).
b) Having GC happen in redisplay makes redisplay hard to code correctly and
slow.
The current status quo does not violate either of these because
a) Lisp code is not in general called from redisplay, only in special cases.
b) GC is prevented from occurring.
Furthermore the only place in the new code where lisp code can currently be
called (where its not already, i.e. I'm discounting widget instantiation)
is mswindows_button_update, so its not a big change. The real problem is
the other way round as I have explained - the redisplay code that the
gutter uses assumes that GC will not occur, this means that the code needs
to happen as if in critical redisplay.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd