* alarm_signal_handler is called too frequently @ 2004-10-13 1:15 YAMAMOTO Mitsuharu 2004-10-13 14:43 ` Richard Stallman 0 siblings, 1 reply; 25+ messages in thread From: YAMAMOTO Mitsuharu @ 2004-10-13 1:15 UTC (permalink / raw) I noticed that alarm_signal_handler was called too frequently on the system that used polling with SIGALRM (such as Solaris/X11 and Mac OS X/Carbon). In alarm_signal_handler, set_alarm is called even when interrupt_input_blocked is non-zero where no timer function is executed. If BLOCK_INPUT continues for a long time, which is typical in Mac OS X/Carbon, set_alarm will set the timer value to 1000 usec because the current time (now) exceeds the old expiration time (atimers->expiration). I think we don't have to call set_alarm when pending_atimers is non-zero because do_pending_atimers is supposed to be called eventually in such a case. Is that correct? The following patch also apparently reduces the CPU usage during the idle time (~1.0% -> 0.0% on my PowerBook G4 667MHz). YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp Index: src/atimer.c =================================================================== RCS file: /cvsroot/emacs/emacs/src/atimer.c,v retrieving revision 1.16 diff -c -r1.16 atimer.c *** src/atimer.c 19 Jul 2004 04:42:43 -0000 1.16 --- src/atimer.c 13 Oct 2004 00:56:47 -0000 *************** *** 397,403 **** EMACS_GET_TIME (now); } ! set_alarm (); } --- 397,404 ---- EMACS_GET_TIME (now); } ! if (!pending_atimers) ! set_alarm (); } ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-13 1:15 alarm_signal_handler is called too frequently YAMAMOTO Mitsuharu @ 2004-10-13 14:43 ` Richard Stallman 2004-10-14 5:16 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 25+ messages in thread From: Richard Stallman @ 2004-10-13 14:43 UTC (permalink / raw) Cc: emacs-devel If BLOCK_INPUT continues for a long time, which is typical in Mac OS X/Carbon, That sounds like a bug to me. BLOCK_INPUT should only be set for short periods of time. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-13 14:43 ` Richard Stallman @ 2004-10-14 5:16 ` YAMAMOTO Mitsuharu 2004-10-17 9:36 ` YAMAMOTO Mitsuharu 0 siblings, 1 reply; 25+ messages in thread From: YAMAMOTO Mitsuharu @ 2004-10-14 5:16 UTC (permalink / raw) Cc: emacs-devel >>>>> On Wed, 13 Oct 2004 10:43:24 -0400, Richard Stallman <rms@gnu.org> said: > If BLOCK_INPUT continues for a long time, which is typical in > Mac OS X/Carbon, > That sounds like a bug to me. BLOCK_INPUT should only be set for > short periods of time. That's not unusual even in X11. For example, BLOCK_INPUT occurs when a popup menu is activated. Then the menu takes control of the user input, and BLOCK_INPUT continues until the user complete the menu operation. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-14 5:16 ` YAMAMOTO Mitsuharu @ 2004-10-17 9:36 ` YAMAMOTO Mitsuharu 2004-10-25 13:13 ` Richard Stallman 0 siblings, 1 reply; 25+ messages in thread From: YAMAMOTO Mitsuharu @ 2004-10-17 9:36 UTC (permalink / raw) >>>>> On Thu, 14 Oct 2004 14:16:25 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said: > For example, BLOCK_INPUT occurs when a popup menu is activated. > Then the menu takes control of the user input, and BLOCK_INPUT > continues until the user complete the menu operation. The frequent call of alarm_signal_handler was observed also on GNU/Linux (with or without GTK) during a popup menu was shown. Could someone answer the original question below? >>>>> On Wed, 13 Oct 2004 10:15:53 +0900, YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> said: > I think we don't have to call set_alarm when pending_atimers is > non-zero because do_pending_atimers is supposed to be called > eventually in such a case. Is that correct? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-17 9:36 ` YAMAMOTO Mitsuharu @ 2004-10-25 13:13 ` Richard Stallman 2004-10-25 14:38 ` Jan D. 0 siblings, 1 reply; 25+ messages in thread From: Richard Stallman @ 2004-10-25 13:13 UTC (permalink / raw) Cc: emacs-devel > For example, BLOCK_INPUT occurs when a popup menu is activated. > Then the menu takes control of the user input, and BLOCK_INPUT > continues until the user complete the menu operation. The frequent call of alarm_signal_handler was observed also on GNU/Linux (with or without GTK) during a popup menu was shown. Could someone answer the original question below? I looked at this just now (please forgive the delay) and found that things seem to be rather messed up. 1. The code makes provision to handle unexpected kinds of keyboard/mouse input while the popup menu is popped up, and to handle timers. That is a nice feature. 2. However, popup_get_selection is called inside BLOCK_INPUT, and it calls timer_check, which can call Lisp code. This seems to be a bug. I don't see any way we could make this safe. I think we have to take out timer processing here. However, I have some doubt that it really works--see below. 3. popup_get_selection is called whenever USE_GTK is not defined, but popup_get_selection is only defined when USE_X_TOOLKIT. I suspect this means that Emacs won't build in the non-toolkit mode any more. Could someone check? I propose the following change as a way to discover problems like #2 sooner. Could people try it and say if it crashes? (Strangely, it does not crash for me when I try C-Mouse-3 just after enabling Font Lock mode on emacs.c. I wonder why.) *** eval.c 30 Jul 2004 23:43:15 -0400 1.221 --- eval.c 25 Oct 2004 05:34:28 -0400 *************** *** 1975,1981 **** struct backtrace backtrace; struct gcpro gcpro1, gcpro2, gcpro3; ! if (handling_signal) abort (); if (SYMBOLP (form)) --- 1985,1991 ---- struct backtrace backtrace; struct gcpro gcpro1, gcpro2, gcpro3; ! if (handling_signal || INPUT_BLOCKED_P) abort (); if (SYMBOLP (form)) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-25 13:13 ` Richard Stallman @ 2004-10-25 14:38 ` Jan D. 2004-10-27 10:47 ` Richard Stallman 0 siblings, 1 reply; 25+ messages in thread From: Jan D. @ 2004-10-25 14:38 UTC (permalink / raw) Cc: YAMAMOTO Mitsuharu, emacs-devel > I looked at this just now (please forgive the delay) and found that > things seem to be rather messed up. > > 1. The code makes provision to handle unexpected kinds of > keyboard/mouse input while the popup menu is popped up, and to handle > timers. That is a nice feature. > > 2. However, popup_get_selection is called inside BLOCK_INPUT, and it > calls timer_check, which can call Lisp code. This seems to be a bug. > > I don't see any way we could make this safe. I think we have to > take out timer processing here. However, I have some doubt that > it really works--see below. > > 3. popup_get_selection is called whenever USE_GTK is not defined, but > popup_get_selection is only defined when USE_X_TOOLKIT. I suspect > this means that Emacs won't build in the non-toolkit mode any more. > Could someone check? It does (FWIW when I update from cvs I run a script that builds the GTK, lesstif, motif, lucid, non-toolkit and non-X versions of Emacs to catch errors like this). That bit is inside a (rather long) section of ifdefs, the structure is like this: #if defined (USE_GTK) || defined (USE_X_TOOLKIT) /* popup_get_selection defined and used here. */ #else /* not USE_X_TOOLKIT && not USE_GTK */ /* Non toolkit code */ #endif so popup_get_selection is not used for the non-toolkit build at all. Jan D. > > > I propose the following change as a way to discover problems like #2 > sooner. Could people try it and say if it crashes? (Strangely, it > does not crash for me when I try C-Mouse-3 just after enabling Font > Lock mode on emacs.c. I wonder why.) It craches, but directly at start before any interaction. Disabling the toolbar (./emacs -q -xrm '*toolBar: 0') makes it start OK, but it does not crash on any popup menu. This is on GNU/Linux, toolkit, GTK and non-toolkit versions. Jan D. > > > *** eval.c 30 Jul 2004 23:43:15 -0400 1.221 > --- eval.c 25 Oct 2004 05:34:28 -0400 > *************** > *** 1975,1981 **** > struct backtrace backtrace; > struct gcpro gcpro1, gcpro2, gcpro3; > > ! if (handling_signal) > abort (); > > if (SYMBOLP (form)) > --- 1985,1991 ---- > struct backtrace backtrace; > struct gcpro gcpro1, gcpro2, gcpro3; > > ! if (handling_signal || INPUT_BLOCKED_P) > abort (); > > if (SYMBOLP (form)) > > > _______________________________________________ > Emacs-devel mailing list > Emacs-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/emacs-devel ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-25 14:38 ` Jan D. @ 2004-10-27 10:47 ` Richard Stallman 2004-10-28 18:02 ` Jan D. 0 siblings, 1 reply; 25+ messages in thread From: Richard Stallman @ 2004-10-27 10:47 UTC (permalink / raw) Cc: mituharu, emacs-devel so popup_get_selection is not used for the non-toolkit build at all. That means item 3 is not a real problem. That is good. > 2. However, popup_get_selection is called inside BLOCK_INPUT, and it > calls timer_check, which can call Lisp code. This seems to be a bug. I still think that is a real problem. It craches, but directly at start before any interaction. Disabling the toolbar (./emacs -q -xrm '*toolBar: 0') makes it start OK, but it does not crash on any popup menu. 1. If it does not crash with popup menus, that could be because no timer was running. Were there any timers that should have run? Maybe something else disables the running of timers from popup_get_selection. In that case, there is no bug here, but the code to check timers is misleading. 2. Is popup_get_selection used, the way you compiled Emacs? 3. Can you debug the crash that does happen? I think anything that causes a crash with this patch has the potential to cause crashes occasionally even without this patch. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-27 10:47 ` Richard Stallman @ 2004-10-28 18:02 ` Jan D. 2004-10-29 1:37 ` YAMAMOTO Mitsuharu 2004-10-31 9:42 ` Richard Stallman 0 siblings, 2 replies; 25+ messages in thread From: Jan D. @ 2004-10-28 18:02 UTC (permalink / raw) Cc: mituharu, emacs-devel Richard Stallman wrote: > so popup_get_selection is not used for the non-toolkit build at all. > > That means item 3 is not a real problem. That is good. > > > 2. However, popup_get_selection is called inside BLOCK_INPUT, and it > > calls timer_check, which can call Lisp code. This seems to be a bug. > > I still think that is a real problem. > > It craches, but directly at start before any interaction. Disabling the > toolbar (./emacs -q -xrm '*toolBar: 0') makes it start OK, but it does > not > crash on any popup menu. > > 1. If it does not crash with popup menus, that could be because no > timer was running. Were there any timers that should have run? Maybe > something else disables the running of timers from > popup_get_selection. In that case, there is no bug here, but the code > to check timers is misleading. Timers are running (scheduled), The version that uses Xt has a timer that runs every 0.1 seconds, and I also have a blinking cursor. But see below. > > 2. Is popup_get_selection used, the way you compiled Emacs? I tried it both ways, i.e. Emacs compiled with Lucid/Motif and GTK/no toolkit. The reason no timers are actualy run is this code in alarm_signal_handler in atimer.c: while (atimers && (pending_atimers = interrupt_input_blocked) == 0 && EMACS_TIME_LE (atimers->expiration, now)) ... Since popups are within BLOCK/UNBLOCK__INPUT, the signal handler just reschedules the alarm without running any timer code. > > 3. Can you debug the crash that does happen? I think anything that > causes a crash with this patch has the potential to cause crashes > occasionally even without this patch. It is because of this code in update_tool_bar, xdisp.c: /* Build desired tool-bar items from keymaps. */ BLOCK_INPUT; f->tool_bar_items = tool_bar_items (f->tool_bar_items, &f->n_tool_bar_items); UNBLOCK_INPUT; The BLOCK/UNBLOCK_INPUT is needed for the GTK version. This was discussed here http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00155.html The solution proposed was to do as the menu code does, first build the structures from Lisp code, then update the GUI. Only the second stage needs to block input. Unfortunately this has not been done yet (on my todo list). Jan D. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-28 18:02 ` Jan D. @ 2004-10-29 1:37 ` YAMAMOTO Mitsuharu 2004-10-29 7:00 ` Jan D. 2004-10-31 9:42 ` Richard Stallman 1 sibling, 1 reply; 25+ messages in thread From: YAMAMOTO Mitsuharu @ 2004-10-29 1:37 UTC (permalink / raw) Cc: rms, emacs-devel >>>>> On Thu, 28 Oct 2004 20:02:13 +0200, "Jan D." <jan.h.d@swipnet.se> said: > Timers are running (scheduled), The version that uses Xt has a timer > that runs every 0.1 seconds, and I also have a blinking cursor. There may be some confusion between two kinds of timers: the OS-level alarm timer and the Emacs-level (cooperative?) timer. The timer for Xt timeout events is the former, and the cursor blinking uses the latter. The function timer_check is also for the latter. > The reason no timers are actualy run is this code in > alarm_signal_handler in atimer.c: > > while (atimers > && (pending_atimers = interrupt_input_blocked) == 0 > && EMACS_TIME_LE (atimers->expiration, now)) > ... > The above code is about the OS-level timer, which I was concerning about in my original message. > Since popups are within BLOCK/UNBLOCK__INPUT, the signal handler > just reschedules the alarm without running any timer code. Actually, the signal handler only sets the interval timer value (set_alarm) without calling schedule_atimer in this situation. The new interval may become a small value, 1msec, by the following code in set_alarm. /* Don't set the interval to 0; this disables the timer. */ if (EMACS_TIME_LE (atimers->expiration, now)) { EMACS_SET_SECS (time, 0); EMACS_SET_USECS (time, 1000); } bzero (&it, sizeof it); it.it_value = time; setitimer (ITIMER_REAL, &it, 0); That's the reason why I did the following question: I think we don't have to call set_alarm when pending_atimers is non-zero because do_pending_atimers is supposed to be called eventually in such a case. Is that correct? YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-29 1:37 ` YAMAMOTO Mitsuharu @ 2004-10-29 7:00 ` Jan D. 2004-10-29 8:24 ` YAMAMOTO Mitsuharu 2004-11-01 7:24 ` Richard Stallman 0 siblings, 2 replies; 25+ messages in thread From: Jan D. @ 2004-10-29 7:00 UTC (permalink / raw) Cc: rms, emacs-devel YAMAMOTO Mitsuharu wrote: > There may be some confusion between two kinds of timers: the OS-level > alarm timer and the Emacs-level (cooperative?) timer. The timer for > Xt timeout events is the former, and the cursor blinking uses the > latter. The function timer_check is also for the latter. Sorry, I misunderstood. The timer_check is not run from popup_get_selection for popup menus because the argument do_timers is 0: if (do_timers && !XtAppPending (Xt_app_con)) timer_check (1); But for dialogs, do_timer is 1, so timers do get checked when a dialog is popped up. However, idle timers are disabled because the event that popups the dialog makes Emacs non-idle. But non-idle timers are run. The check for INPUT_BLOCKED_P proposed by Richard in Feval does detect this: if (handling_signal || INPUT_BLOCKED_P) abort (); I guess we just have to get rid of the call to timer_check in popup_get_selection. > >>Since popups are within BLOCK/UNBLOCK__INPUT, the signal handler >>just reschedules the alarm without running any timer code. > > > Actually, the signal handler only sets the interval timer value > (set_alarm) without calling schedule_atimer in this situation. The > new interval may become a small value, 1msec, by the following code in > set_alarm. > > /* Don't set the interval to 0; this disables the timer. */ > if (EMACS_TIME_LE (atimers->expiration, now)) > { > EMACS_SET_SECS (time, 0); > EMACS_SET_USECS (time, 1000); > } > > bzero (&it, sizeof it); > it.it_value = time; > setitimer (ITIMER_REAL, &it, 0); By "reschedules the alarm" I meant that the code arranges for another SIGALRM to be delivered. And yes, the time is 1 millisecond. > > That's the reason why I did the following question: > > I think we don't have to call set_alarm when pending_atimers is > non-zero because do_pending_atimers is supposed to be called > eventually in such a case. Is that correct? You mean like this? Index: atimer.c *** atimer.c.~1.16.~ 2004-07-19 12:53:25.000000000 +0200 --- atimer.c 2004-10-29 08:56:37.000000000 +0200 *************** *** 397,402 **** --- 397,403 ---- EMACS_GET_TIME (now); } + if (! (pending_atimers && interrupt_input_blocked)) set_alarm (); } That works and should save a couple of CPU cycles. Jan D. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-29 7:00 ` Jan D. @ 2004-10-29 8:24 ` YAMAMOTO Mitsuharu 2004-11-01 7:24 ` Richard Stallman 1 sibling, 0 replies; 25+ messages in thread From: YAMAMOTO Mitsuharu @ 2004-10-29 8:24 UTC (permalink / raw) Cc: rms, emacs-devel >>>>> On Fri, 29 Oct 2004 09:00:14 +0200, "Jan D." <jan.h.d@swipnet.se> said: >> That's the reason why I did the following question: >> >> I think we don't have to call set_alarm when pending_atimers is >> non-zero because do_pending_atimers is supposed to be called >> eventually in such a case. Is that correct? > You mean like this? > + if (! (pending_atimers && interrupt_input_blocked)) > set_alarm (); > That works and should save a couple of CPU cycles. I've been using the similar patch in http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg00553.html for two weeks on Solaris/X11 and Mac OS X/Carbon, and it seems to work fine for me. Reduction of CPU cycles is prominent in Mac OS X/Carbon where BLOCK_INPUT is enabled for a long time while waiting for some user input in sys_select (mac.c). We need BLOCK_INPUT (or something like this) here because the only way to know whether input is available or not is to call ReceiveNextEvent, and this function is not reentrant. I think we don't have to poll input with signal while waiting for input. YAMAMOTO Mitsuharu mituharu@math.s.chiba-u.ac.jp ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-29 7:00 ` Jan D. 2004-10-29 8:24 ` YAMAMOTO Mitsuharu @ 2004-11-01 7:24 ` Richard Stallman 2004-11-01 9:06 ` Jan D. 1 sibling, 1 reply; 25+ messages in thread From: Richard Stallman @ 2004-11-01 7:24 UTC (permalink / raw) Cc: mituharu, emacs-devel Sorry, I misunderstood. The timer_check is not run from popup_get_selection for popup menus because the argument do_timers is 0: if (do_timers && !XtAppPending (Xt_app_con)) timer_check (1); But for dialogs, do_timer is 1, so timers do get checked when a dialog is popped up. Can anyone figure out why these two cases uses different values for do_timer? They also use different values for down_on_keypress. cthose arguments are clearly there so that the two callers could treat these differently. There must have been a reason. I guess we just have to get rid of the call to timer_check in popup_get_selection. I guess we do. Will this mean that the cursor doesn't blink? If so, it would be good to make sure that the cursor is ON rather than off. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-11-01 7:24 ` Richard Stallman @ 2004-11-01 9:06 ` Jan D. 2004-11-01 12:21 ` Jan D. 2004-11-02 14:08 ` Richard Stallman 0 siblings, 2 replies; 25+ messages in thread From: Jan D. @ 2004-11-01 9:06 UTC (permalink / raw) Cc: mituharu, emacs-devel Richard Stallman wrote: > Sorry, I misunderstood. The timer_check is not run from popup_get_selection > for popup menus because the argument do_timers is 0: > > if (do_timers && !XtAppPending (Xt_app_con)) > timer_check (1); > > But for dialogs, do_timer is 1, so timers do get checked when a dialog is > popped up. > > Can anyone figure out why these two cases uses different values for > do_timer? They also use different values for down_on_keypress. > cthose arguments are clearly there so that the two callers could treat > these differently. There must have been a reason. I can't say why the do_timer argument is different, the modification was made by you almost 2 years ago: 2002-12-21 Richard M. Stallman <rms@gnu.org> * xmenu.c (popup_get_selection): Now static. New arg DO_TIMERS. If it is non-nil, run timers. Use an unwind-protect to requeue the events that were read ahead. (popup_get_selection_unwind): New subroutine. (popup_get_selection_queue): File-scope variable now holds that queue. (xmenu_show): Pass 0 for DO_TIMERS to popup_get_selection. (xdialog_show): Pass 1 for DO_TIMERS to popup_get_selection. Use an unwind-protect to pop down the dialog box. (xdialog_show_unwind): New subroutine implements that. I can speculate that since popup menus does a grab and dialog does not, there might have been some difference in event handling. The reason for the difference in down_on_keypress is that when a popup menu is up, the keyboard is grabbed, so no keypresses goes to the Emacs frame anyway. But for a dialog there might be events that goes to the Emacs frame (for example if you have focus-follows-mouse and the focus is not on the dialog, but on the frame). For such events the dialog is popped down (as per the old behaviour from previous Emacs versions). > > I guess we just have to get rid of the call to timer_check in > popup_get_selection. > > I guess we do. Will this mean that the cursor doesn't blink? > If so, it would be good to make sure that the cursor is ON > rather than off. Yes, it means that the cursor does not blink for popup menus or dialogs. This is the same as for Emacs 21.2 (the oldest I have here). The difference is that in CVS Emacs the cursor turns hollow when a dialog or menu is popped up, previously it stayed solid. Jan D. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-11-01 9:06 ` Jan D. @ 2004-11-01 12:21 ` Jan D. 2004-11-02 14:08 ` Richard Stallman 1 sibling, 0 replies; 25+ messages in thread From: Jan D. @ 2004-11-01 12:21 UTC (permalink / raw) Cc: Richard Stallman > The reason for the difference in down_on_keypress is that when a popup > menu is up, the keyboard is grabbed, so no keypresses goes to the > Emacs frame anyway. ... and most importantly, you can navigate a popup menu (Lucid) with arrow keys (now that I fixed a bug that crashed Emacs). We don't want the arrow keys to pop the menu down. ESC can be used to pop the menu down. Jan D. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-11-01 9:06 ` Jan D. 2004-11-01 12:21 ` Jan D. @ 2004-11-02 14:08 ` Richard Stallman 2004-11-02 21:56 ` Jan D. 2004-11-04 13:02 ` Jan D. 1 sibling, 2 replies; 25+ messages in thread From: Richard Stallman @ 2004-11-02 14:08 UTC (permalink / raw) Cc: mituharu, emacs-devel I can't say why the do_timer argument is different, the modification was made by you almost 2 years ago: Judging by the date when I made the change, I was probably looking at bug reports saved up from the previous months. I didn't mail the patch to anyone at the time. Perhaps it has to do with y-or-n-p-with-timeout. Can that operate with a dialog? If so, it now won't work correctly; the timeout will be ignored. We could make the timeout work once again using some other mechanism, I guess. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-11-02 14:08 ` Richard Stallman @ 2004-11-02 21:56 ` Jan D. 2004-11-03 17:04 ` Richard Stallman 2004-11-04 13:02 ` Jan D. 1 sibling, 1 reply; 25+ messages in thread From: Jan D. @ 2004-11-02 21:56 UTC (permalink / raw) Cc: mituharu, emacs-devel Richard Stallman wrote: > I can't say why the do_timer argument is different, the modification was made > by you almost 2 years ago: > > Judging by the date when I made the change, I was probably looking at > bug reports saved up from the previous months. I didn't mail the > patch to anyone at the time. > > Perhaps it has to do with y-or-n-p-with-timeout. > Can that operate with a dialog? If so, it now won't work > correctly; the timeout will be ignored. We could make > the timeout work once again using some other mechanism, > I guess. y-or-n-p-with-timeout will pop up a dialog when invoked with the mouse (i.e. tool or menu bar). And yes, it will not time out. It never did for GTK or Mac OSX BTW, as they do not process timers if a dialog is popped up. Currently there are no such menu or tool bar entries, but I guess other packages may add such an item. But I was wondering if the differences in how dialogs and menus are invoked may make a difference. A menu is invoked as a result of a KeyPress, which arrives in the signal handler. But a dialog is always popped up by lisp code, not directly from the signal handler. Does this matter? Jan D. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-11-02 21:56 ` Jan D. @ 2004-11-03 17:04 ` Richard Stallman 2004-11-03 17:26 ` Jan D. 2004-11-04 22:41 ` Jan D. 0 siblings, 2 replies; 25+ messages in thread From: Richard Stallman @ 2004-11-03 17:04 UTC (permalink / raw) Cc: mituharu, emacs-devel y-or-n-p-with-timeout will pop up a dialog when invoked with the mouse (i.e. tool or menu bar). And yes, it will not time out. It never did for GTK or Mac OSX BTW, as they do not process timers if a dialog is popped up. Currently there are no such menu or tool bar entries, but I guess other packages may add such an item. I think we either should implement y-or-n-p-with-timeout correctly or give up on doing so. If we give up, we should mark it obsolete now. Which do people think we should do? But I was wondering if the differences in how dialogs and menus are invoked may make a difference. A menu is invoked as a result of a KeyPress, which arrives in the signal handler. Are you thinking of the menu bar? I think this code is concerned only with popup menus; they are invoked with x-popup-menu, which is analogous to x-popup-dialog. So it has nothing to do with KeyPress. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-11-03 17:04 ` Richard Stallman @ 2004-11-03 17:26 ` Jan D. 2004-11-04 20:42 ` Richard Stallman 2004-11-04 22:41 ` Jan D. 1 sibling, 1 reply; 25+ messages in thread From: Jan D. @ 2004-11-03 17:26 UTC (permalink / raw) Cc: mituharu, emacs-devel > Are you thinking of the menu bar? I think this code is concerned only > with popup menus; they are invoked with x-popup-menu, which is > analogous to x-popup-dialog. So it has nothing to do with KeyPress. Duh, I meant ButtonPress. Anyway, both popup menus and dialogs are equal in this regard. Jan D. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-11-03 17:26 ` Jan D. @ 2004-11-04 20:42 ` Richard Stallman 0 siblings, 0 replies; 25+ messages in thread From: Richard Stallman @ 2004-11-04 20:42 UTC (permalink / raw) Cc: mituharu, emacs-devel > Are you thinking of the menu bar? I think this code is concerned only > with popup menus; they are invoked with x-popup-menu, which is > analogous to x-popup-dialog. So it has nothing to do with KeyPress. Duh, I meant ButtonPress. Anyway, both popup menus and dialogs are equal in this regard. Yes, but I think neither of them is invoked with ButtonPress. They are called by Lisp and from read_char_x_menu_prompt. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-11-03 17:04 ` Richard Stallman 2004-11-03 17:26 ` Jan D. @ 2004-11-04 22:41 ` Jan D. 2004-11-05 12:36 ` Kim F. Storm 1 sibling, 1 reply; 25+ messages in thread From: Jan D. @ 2004-11-04 22:41 UTC (permalink / raw) Cc: mituharu, emacs-devel I made my question very unclear, I'll try again. Sorry if this is obvious for others, but I just don't understand. Say we have three functions, aL, bL and cL, all written in Lisp (hence the L). Now, obviously aL calling bL calling cL is safe (<-- denotes return, not cL calls bL). 1: aL bL cL | --> | | | | --> | | | <-- | | <-- | | If we replace bL with code in C instead, is this safe? 2: aL bC cL | --> | | | | --> | | | <-- | | <-- | | I think it must be, there are places in Emacs where C code calls Lisp functions. Say now that bC calls cL within BLOCK/UNBLOCK_INPUT: 3: aL bC cL | --> | | | BLOCK | | | --> | | | <-- | | UNBLOCK | | <-- | | Why is this unsafe, if 2 was safe (if indeed it is)? It is not as though the signal handler is calling Lisp code, that is obviously unsafe. But when a dialog or popup menu is popped up, the signal handler is not involved in processing X events, it is all done inside bC. I'm sorry if this is a stupid question, but I just don't get it. Jan D. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-11-04 22:41 ` Jan D. @ 2004-11-05 12:36 ` Kim F. Storm 2004-11-06 5:22 ` Richard Stallman 0 siblings, 1 reply; 25+ messages in thread From: Kim F. Storm @ 2004-11-05 12:36 UTC (permalink / raw) Cc: rms, mituharu, emacs-devel I don't get it either. Why is it unsafe to Feval with input blocked? Actually, to me it seems to be safer to do it while input is blocked! "Jan D." <jan.h.d@swipnet.se> writes: > I made my question very unclear, I'll try again. Sorry if this is > obvious for others, but I just don't understand. > > Say we have three functions, aL, bL and cL, all written in Lisp (hence > the L). Now, obviously aL calling bL calling cL is safe (<-- denotes > return, not cL calls bL). > > 1: > > aL bL cL > | --> | | > | | --> | > | | <-- | > | <-- | | > > If we replace bL with code in C instead, is this safe? > > 2: > > aL bC cL > | --> | | > | | --> | > | | <-- | > | <-- | | > > I think it must be, there are places in Emacs where C code calls Lisp > functions. Say now that bC calls cL within BLOCK/UNBLOCK_INPUT: > > 3: > > aL bC cL > | --> | | > | BLOCK | > | | --> | > | | <-- | > | UNBLOCK | > | <-- | | > > Why is this unsafe, if 2 was safe (if indeed it is)? It is not as > though the signal handler is calling Lisp code, that is obviously > unsafe. But when a dialog or popup menu is popped up, the signal > handler is not involved in processing X events, it is all done inside > bC. > > I'm sorry if this is a stupid question, but I just don't get it. > > Jan D. > -- Kim F. Storm <storm@cua.dk> http://www.cua.dk ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-11-05 12:36 ` Kim F. Storm @ 2004-11-06 5:22 ` Richard Stallman 0 siblings, 0 replies; 25+ messages in thread From: Richard Stallman @ 2004-11-06 5:22 UTC (permalink / raw) Cc: jan.h.d, mituharu, emacs-devel Why is it unsafe to Feval with input blocked? I thought that this was not handled at all, and wouldn't have a chance of working right. But I can't find a reason now why it won't work. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-11-02 14:08 ` Richard Stallman 2004-11-02 21:56 ` Jan D. @ 2004-11-04 13:02 ` Jan D. 1 sibling, 0 replies; 25+ messages in thread From: Jan D. @ 2004-11-04 13:02 UTC (permalink / raw) Cc: rms Richard Stallman wrote: > I can't say why the do_timer argument is different, the modification was made > by you almost 2 years ago: > > Judging by the date when I made the change, I was probably looking at > bug reports saved up from the previous months. I didn't mail the > patch to anyone at the time. > > Perhaps it has to do with y-or-n-p-with-timeout. > Can that operate with a dialog? If so, it now won't work > correctly; the timeout will be ignored. We could make > the timeout work once again using some other mechanism, > I guess. I think that is the case, there was a bug report on bug-gnu-emacs about it 4 days before the checkin, http://lists.gnu.org/archive/html/bug-gnu-emacs/2002-12/msg00062.html: > From: Järneström Jonas > Subject: y-or-n-p-with-timeout fails when using dialog box input > Date: Mon, 16 Dec 2002 18:31:35 +0100 (MET) > > In GNU Emacs 20.7.1 (sparc-sun-solaris2.8, X toolkit) > of Tue Jan 16 2001 on sunray8.era-a.ericsson.se > configured using `configure --prefix=/usr/bag/emacs/20.7 > --datadir=/usr/bag/emacs/share' > > See the funs below. > When I run the first one, timeout never happens. > When I run the second one, timeout works ok. > Why dont I get the timeout when using the dialog box input method? > > Thanks, > Jonas Jarnestrom > > (defun dialog-box-timeout-never-happens () > (let* ((last-nonmenu-event nil)) > (y-or-n-p-with-timeout "prompt" 3 'timeout))) > > (defun minibuffer-timeout-works () > (let* ((foo nil)) > (y-or-n-p-with-timeout "prompt" 3 'timeout))) Jan D. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-28 18:02 ` Jan D. 2004-10-29 1:37 ` YAMAMOTO Mitsuharu @ 2004-10-31 9:42 ` Richard Stallman 2004-10-31 15:11 ` Jan D. 1 sibling, 1 reply; 25+ messages in thread From: Richard Stallman @ 2004-10-31 9:42 UTC (permalink / raw) Cc: mituharu, emacs-devel The BLOCK/UNBLOCK_INPUT is needed for the GTK version. This was discussed here http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00155.html The solution proposed was to do as the menu code does, first build the structures from Lisp code, then update the GUI. Only the second stage needs to block input. Unfortunately this has not been done yet (on my todo list). So the cause is a real bug, albeit not one unknown. When do you think you'll be able to do make this change? We need it before the release. (I will add it to FOR-RELEASE.) ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: alarm_signal_handler is called too frequently 2004-10-31 9:42 ` Richard Stallman @ 2004-10-31 15:11 ` Jan D. 0 siblings, 0 replies; 25+ messages in thread From: Jan D. @ 2004-10-31 15:11 UTC (permalink / raw) Cc: mituharu, emacs-devel Richard Stallman wrote: > The BLOCK/UNBLOCK_INPUT is needed for the GTK version. This was discussed here > http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-05/msg00155.html > > The solution proposed was to do as the menu code does, first build the > structures from Lisp code, then update the GUI. Only the second stage needs to > block input. Unfortunately this has not been done yet (on my todo list). > > So the cause is a real bug, albeit not one unknown. > > When do you think you'll be able to do make this change? > We need it before the release. (I will add it to FOR-RELEASE.) I've checked in the change. Jan D. ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2004-11-06 5:22 UTC | newest] Thread overview: 25+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2004-10-13 1:15 alarm_signal_handler is called too frequently YAMAMOTO Mitsuharu 2004-10-13 14:43 ` Richard Stallman 2004-10-14 5:16 ` YAMAMOTO Mitsuharu 2004-10-17 9:36 ` YAMAMOTO Mitsuharu 2004-10-25 13:13 ` Richard Stallman 2004-10-25 14:38 ` Jan D. 2004-10-27 10:47 ` Richard Stallman 2004-10-28 18:02 ` Jan D. 2004-10-29 1:37 ` YAMAMOTO Mitsuharu 2004-10-29 7:00 ` Jan D. 2004-10-29 8:24 ` YAMAMOTO Mitsuharu 2004-11-01 7:24 ` Richard Stallman 2004-11-01 9:06 ` Jan D. 2004-11-01 12:21 ` Jan D. 2004-11-02 14:08 ` Richard Stallman 2004-11-02 21:56 ` Jan D. 2004-11-03 17:04 ` Richard Stallman 2004-11-03 17:26 ` Jan D. 2004-11-04 20:42 ` Richard Stallman 2004-11-04 22:41 ` Jan D. 2004-11-05 12:36 ` Kim F. Storm 2004-11-06 5:22 ` Richard Stallman 2004-11-04 13:02 ` Jan D. 2004-10-31 9:42 ` Richard Stallman 2004-10-31 15:11 ` Jan D.
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.