* Re: Profiling font-lock in xemacs
@ 2002-06-27 21:55 Ben Wing
0 siblings, 0 replies; 9+ messages in thread
From: Ben Wing @ 2002-06-27 21:55 UTC (permalink / raw)
Cc: ben, bws, xemacs-design, emacs-devel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Profiling font-lock in xemacs @ 2002-06-29 19:34 Ben Wing 0 siblings, 0 replies; 9+ messages in thread From: Ben Wing @ 2002-06-29 19:34 UTC (permalink / raw) Cc: monnier+gnu/emacs, ben, bws, xemacs-design, emacs-devel >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 worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <F102hm4mRK4dGDNhxKL00000226@hotmail.com>]
* Re: Profiling font-lock in xemacs [not found] <F102hm4mRK4dGDNhxKL00000226@hotmail.com> @ 2002-06-29 8:41 ` Richard Stallman 0 siblings, 0 replies; 9+ messages in thread From: Richard Stallman @ 2002-06-29 8:41 UTC (permalink / raw) Cc: monnier+gnu/emacs, ben, bws, xemacs-design, emacs-devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <200205300129.17083.bws@deepcopy.org>]
[parent not found: <87d6vet7f2.fsf@tleepslib.sk.tsukuba.ac.jp>]
[parent not found: <5l3cw9lob0.fsf@rum.cs.yale.edu>]
[parent not found: <200205301939.02926.bws@deepcopy.org>]
[parent not found: <005d01c21835$344dc340$0201a8c0@neeeeeee>]
[parent not found: <200206201517.g5KFHaw07020@rum.cs.yale.edu>]
[parent not found: <009301c218f1$8e5a9040$0201a8c0@neeeeeee>]
[parent not found: <200206211911.g5LJBvN12715@rum.cs.yale.edu>]
[parent not found: <026d01c21991$ede47580$0201a8c0@neeeeeee>]
* Re: Profiling font-lock in xemacs [not found] ` <026d01c21991$ede47580$0201a8c0@neeeeeee> @ 2002-06-22 17:32 ` Stefan Monnier 2002-06-23 4:53 ` Stephen J. Turnbull ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Stefan Monnier @ 2002-06-22 17:32 UTC (permalink / raw) Cc: Ben Wing, bws, xemacs-design, emacs-devel > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Profiling font-lock in xemacs 2002-06-22 17:32 ` Stefan Monnier @ 2002-06-23 4:53 ` Stephen J. Turnbull 2002-06-23 18:12 ` Richard Stallman [not found] ` <200206231812.g5NICe024443@aztec.santafe.edu> 2 siblings, 0 replies; 9+ messages in thread From: Stephen J. Turnbull @ 2002-06-23 4:53 UTC (permalink / raw) Cc: Ben Wing, Ben Wing, bws, xemacs-design, emacs-devel >>>>> "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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Profiling font-lock in xemacs 2002-06-22 17:32 ` Stefan Monnier 2002-06-23 4:53 ` Stephen J. Turnbull @ 2002-06-23 18:12 ` Richard Stallman [not found] ` <200206231812.g5NICe024443@aztec.santafe.edu> 2 siblings, 0 replies; 9+ messages in thread From: Richard Stallman @ 2002-06-23 18:12 UTC (permalink / raw) Cc: ben_wing, ben, bws, xemacs-design, emacs-devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <200206231812.g5NICe024443@aztec.santafe.edu>]
* Re: Profiling font-lock in xemacs [not found] ` <200206231812.g5NICe024443@aztec.santafe.edu> @ 2002-06-23 18:40 ` Stefan Monnier [not found] ` <200206231840.g5NIeaa30522@rum.cs.yale.edu> 1 sibling, 0 replies; 9+ messages in thread From: Stefan Monnier @ 2002-06-23 18:40 UTC (permalink / raw) Cc: monnier+gnu/emacs, ben_wing, ben, bws, xemacs-design, emacs-devel > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <200206231840.g5NIeaa30522@rum.cs.yale.edu>]
* Re: Profiling font-lock in xemacs [not found] ` <200206231840.g5NIeaa30522@rum.cs.yale.edu> @ 2002-06-24 19:39 ` Richard Stallman [not found] ` <200206241939.g5OJdsk26260@aztec.santafe.edu> 1 sibling, 0 replies; 9+ messages in thread From: Richard Stallman @ 2002-06-24 19:39 UTC (permalink / raw) Cc: monnier+gnu/emacs, ben_wing, ben, bws, xemacs-design, emacs-devel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <200206241939.g5OJdsk26260@aztec.santafe.edu>]
* Re: Profiling font-lock in xemacs [not found] ` <200206241939.g5OJdsk26260@aztec.santafe.edu> @ 2002-06-24 20:04 ` Stefan Monnier 0 siblings, 0 replies; 9+ messages in thread From: Stefan Monnier @ 2002-06-24 20:04 UTC (permalink / raw) Cc: monnier+gnu/emacs, ben_wing, ben, bws, xemacs-design, emacs-devel > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2002-06-29 19:34 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-06-27 21:55 Profiling font-lock in xemacs Ben Wing -- strict thread matches above, loose matches on Subject: below -- 2002-06-29 19:34 Ben Wing [not found] <F102hm4mRK4dGDNhxKL00000226@hotmail.com> 2002-06-29 8:41 ` Richard Stallman [not found] <200205300129.17083.bws@deepcopy.org> [not found] ` <87d6vet7f2.fsf@tleepslib.sk.tsukuba.ac.jp> [not found] ` <5l3cw9lob0.fsf@rum.cs.yale.edu> [not found] ` <200205301939.02926.bws@deepcopy.org> [not found] ` <005d01c21835$344dc340$0201a8c0@neeeeeee> [not found] ` <200206201517.g5KFHaw07020@rum.cs.yale.edu> [not found] ` <009301c218f1$8e5a9040$0201a8c0@neeeeeee> [not found] ` <200206211911.g5LJBvN12715@rum.cs.yale.edu> [not found] ` <026d01c21991$ede47580$0201a8c0@neeeeeee> 2002-06-22 17:32 ` Stefan Monnier 2002-06-23 4:53 ` Stephen J. Turnbull 2002-06-23 18:12 ` Richard Stallman [not found] ` <200206231812.g5NICe024443@aztec.santafe.edu> 2002-06-23 18:40 ` Stefan Monnier [not found] ` <200206231840.g5NIeaa30522@rum.cs.yale.edu> 2002-06-24 19:39 ` Richard Stallman [not found] ` <200206241939.g5OJdsk26260@aztec.santafe.edu> 2002-06-24 20:04 ` Stefan Monnier
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).