Re: Profiling font-lock in xemacs

Re: Profiling font-lock in xemacs

[Stefan Monnier]

> urk!  one of the absolute worst things about gnu emacs is its tendency to do
> so much inside of signal handlers.  xemacs does *nothing* whatsoever in any
> signal handlers except set a flag.  This includes sigchld.  we've eliminated
> "immediate_quit", all of that "block_input" crap, etc.  the only exception
> is a flag that allows a longjmp[] from a signal handler to interrupt certain
> i/o operations that don't return EINTR on SIGIO, e.g. connect[].

> I made all the changes to remove this stuff and it was fairly easy; you
> might consider the same.  it was very satisfying to delete so much crud
> in the process.

Agreed.


	Stefan

Re: Profiling font-lock in xemacs

[Stephen J. Turnbull]

>>>>> "Stefan" == Stefan Monnier <monnier+gnu/emacs@rum.cs.yale.edu> writes:

    >> I made all the changes to remove this stuff and it was fairly
    >> easy; you might consider the same.  it was very satisfying to
    >> delete so much crud in the process.

    Stefan> Agreed.

Riding Guido's time machine again?  Is this one also in CVS as of the
time of receipt? ;-)


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
 My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so its faults I remember.  Scott Gilbert c.l.py

Re: Profiling font-lock in xemacs

[Richard Stallman]

Emacs does not do very much in signal handlers now.  For sigchld it
just records the status, something that is best done right away.
XTread_socket is complex; if some of that can be done later on, that
might be good.  But it can't wait too long.  For instance, quit has to
be detected reasonably soon.  Perhaps the QUIT macro could run the
code to process the input.

On the other hand, this code works; we have had little problem with
it for a long time.

Re: Profiling font-lock in xemacs

[Stefan Monnier]

> Emacs does not do very much in signal handlers now.  For sigchld it
> just records the status, something that is best done right away.
> XTread_socket is complex; if some of that can be done later on, that
> might be good.  But it can't wait too long.  For instance, quit has to
> be detected reasonably soon.  Perhaps the QUIT macro could run the
> code to process the input.
> 
> On the other hand, this code works; we have had little problem with
> it for a long time.

The problem is indeed XTread_socket.  It is complex and it has
introduced really nasty bugs which were very difficult to trace.
Also, it is dangerous to try to extend its functionality because
it is run asynchronously (the recent "selected-window follows mouse"
patch is a case in point).

I think it would be worth it to try and move the bulk of it out of the
signal handler as the XEmacs folks did.  I haven't checked when the do
the "check for input".  Doing it from QUIT is indeed one obvious
possibility.


	Stefan

Re: Profiling font-lock in xemacs

[Richard Stallman]

    The problem is indeed XTread_socket.  It is complex and it has
    introduced really nasty bugs which were very difficult to trace.

I don't think it has been demanding a lot of attention lately.

Re: Profiling font-lock in xemacs

[Stefan Monnier]

>     The problem is indeed XTread_socket.  It is complex and it has
>     introduced really nasty bugs which were very difficult to trace.
> I don't think it has been demanding a lot of attention lately.

Lately, probably not.  But (Gerd and) I spent a lot of time
tracking down two bugs with it during (and just before) the Emacs-21
pretest period.  And I'm sure there are some left, although
their occurrence is rare enough that we don't notice them.

But as I said, another problem is the fact that some improvements
are harder to implement because of the restriction about what can be
done from within XTread_socket.


	Stefan

Re: Profiling font-lock in xemacs

[Ben Wing]

what we do is something like this:

--all the signal handler does is set a flag. (this flag also gets set by a 
0.25-second asynchronous timer, on systems like MS Windows that have no 
SIGIO.)

--QUIT notices this, which causes it (on most platforms) to drain the input 
queue, storing it into an internal "dispatch queue".  we iterate through 
this to look for C-g. (under X we actually use something like XCheckIfInput 
(i forget the proper name) instead of draining the queue, but that's bogus 
and left over from a long time ago and should be fixed like the other 
platforms.) the dispatch queue is one of the sources of next-event (your 
read-event).

i don't think sigchld should do *anything* except set a flag.

ben

>From: "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>
>To: Richard Stallman <rms@gnu.org>
>CC: monnier+gnu/emacs@rum.cs.yale.edu, ben_wing@hotmail.com, ben@666.com,   
>bws@deepcopy.org, xemacs-design@xemacs.org, emacs-devel@gnu.org
>Subject: Re: Profiling font-lock in xemacs
>Date: Sun, 23 Jun 2002 14:40:36 -0400
>
> > Emacs does not do very much in signal handlers now.  For sigchld it
> > just records the status, something that is best done right away.
> > XTread_socket is complex; if some of that can be done later on, that
> > might be good.  But it can't wait too long.  For instance, quit has to
> > be detected reasonably soon.  Perhaps the QUIT macro could run the
> > code to process the input.
> >
> > On the other hand, this code works; we have had little problem with
> > it for a long time.
>
>The problem is indeed XTread_socket.  It is complex and it has
>introduced really nasty bugs which were very difficult to trace.
>Also, it is dangerous to try to extend its functionality because
>it is run asynchronously (the recent "selected-window follows mouse"
>patch is a case in point).
>
>I think it would be worth it to try and move the bulk of it out of the
>signal handler as the XEmacs folks did.  I haven't checked when the do
>the "check for input".  Doing it from QUIT is indeed one obvious
>possibility.
>
>
>	Stefan
>




_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

Re: Profiling font-lock in xemacs

[Richard Stallman]

It would be better not to have a delay of even .25 second in handling
C-g.  It ought to respond crisply.

If the delay were made smaller, eventually it would be insignificant.
I don't know at what point that is reached.

Currently on some systems C-g handling can involve a delay of up to 1
second, the wait for "polling for input".  That's because when it was
implemented there was no better facility to use than `alarm'.
Nowadays I gather there is one; we should change the polling interval
to something shorter than a second.

Re: Profiling font-lock in xemacs

[Ben Wing]

>From: Richard Stallman <rms@gnu.org>
>Reply-To: rms@gnu.org
>To: ben_wing@hotmail.com
>CC: monnier+gnu/emacs@rum.cs.yale.edu, ben@666.com, bws@deepcopy.org,   
>xemacs-design@xemacs.org, emacs-devel@gnu.org
>Subject: Re: Profiling font-lock in xemacs
>Date: Sat, 29 Jun 2002 02:41:06 -0600 (MDT)
>
>It would be better not to have a delay of even .25 second in handling
>C-g.  It ought to respond crisply.

of course, this is only on systems without SIGIO, where we have no choice 
but to implement such a thing.

>
>If the delay were made smaller, eventually it would be insignificant.
>I don't know at what point that is reached.

.25 second is pretty small.  the smaller you go, of course, the more cpu 
time you potentially use up.


>
>Currently on some systems C-g handling can involve a delay of up to 1
>second, the wait for "polling for input".  That's because when it was
>implemented there was no better facility to use than `alarm'.
>Nowadays I gather there is one; we should change the polling interval
>to something shorter than a second.

setitimer() on unix systems.





_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com