Emacs does not listen on w32

Emacs does not listen on w32

[Lennart Borgman (gmail)]

I made a mistake when essentially changed the fontify-region-function I 
used. This lead to Emacs looping updating the echo area with new 
messages (trace messages), but not listening even to the OS events. I 
clicked the upper right X to try to close Emacs, but nothing happened.

I even had to shut off the pc power since I could not get the Windows 
Task Manager to come up.

It looks to me there must be two bugs here:

- Emacs not giving up cpu to windows.
- Emacs is not listening to OS events when it executes lisp code.

Re: Emacs does not listen on w32

[Stefan Monnier]

> I made a mistake when essentially changed the fontify-region-function
> I used.  This lead to Emacs looping updating the echo area with new
> messages (trace messages), but not listening even to the OS events.
> I clicked the upper right X to try to close Emacs, but
> nothing happened.

> I even had to shut off the pc power since I could not get the Windows Task
> Manager to come up.

> It looks to me there must be two bugs here:

> - Emacs not giving up cpu to windows.

This would be a bug (or shortcoming) in the OS: the application never
has to "relinquish the CPU" because the OS preempts the
application instead.  But it's surprisingly difficult for an OS to make
sure that it's *always* responsive no matter what the applications do.

My guess is that Emacs started to eat up memory, causing the machine to
thrash, which is the typical situation where the OS becomes unresponsive.

> - Emacs is not listening to OS events when it executes lisp code.

Emacs does listen.  You've hit some bug somewhere.


        Stefan

Re: Emacs does not listen on w32

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> It looks to me there must be two bugs here:
>
> - Emacs not giving up cpu to windows.

Since Windows NT 3.1 and 95, multitasking has been pre-emptive 
(controlled by the OS), not co-operative (controlled by applications).
If Windows does not allow you to use other programs when Emacs is busy, 
that is a problem with Windows, not with Emacs. Emacs should not have to 
"give up CPU", that is an osolete concept from the co-operative 
multitasking days.

> - Emacs is not listening to OS events when it executes lisp code.

You are trying to cleanly kill Emacs. That involves running Lisp code, 
so the lisp interpreter needs to finish the infinite loop you told it to 
execute before it gets to cleaning up and exiting.  The usual workaround 
in such a case is to terminate Emacs uncleanly.

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> It looks to me there must be two bugs here:
>>
>> - Emacs not giving up cpu to windows.
> 
> Since Windows NT 3.1 and 95, multitasking has been pre-emptive 
> (controlled by the OS), not co-operative (controlled by applications).
> If Windows does not allow you to use other programs when Emacs is busy, 
> that is a problem with Windows, not with Emacs. Emacs should not have to 
> "give up CPU", that is an osolete concept from the co-operative 
> multitasking days.

Yes, Stefan and you are right here of course. My bad, I did not express 
my self very good.

Stefan replied that it could be a problem with memory consumption 
instead since this can be hard for the OS to cope with. Another 
possibility is perhaps that the message queue is blocked.

>> - Emacs is not listening to OS events when it executes lisp code.
> 
> You are trying to cleanly kill Emacs. That involves running Lisp code, 
> so the lisp interpreter needs to finish the infinite loop you told it to 
> execute before it gets to cleaning up and exiting.  The usual workaround 
> in such a case is to terminate Emacs uncleanly.

I would expect that the message sent to the Emacs when clicking on the 
upper left [X] would terminate any loop, just like C-g terminates a loop 
in a command.

Re: Emacs does not listen on w32

[Juanma Barranquero]

On Sun, Apr 13, 2008 at 4:04 PM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

>  I would expect that the message sent to the Emacs when clicking on the
> upper left [X] would terminate any loop, just like C-g terminates a loop in
> a command.

keyboard-quit's function is to signal a `quit' condition, so it does it.

Clicking the upper left [X] sends a WM_CLOSE message to Emacs, which
tells it to do an orderly exit. That includes executing Lisp code, and
potentially doing a lot of things: writing files, asking the user,
killing subprocesses, etc. If some of these things take forever, how
it is Emacs to know that it is a bug and not expected behavior? For
example, if something in kill-emacs-query-functions asks me and I
don't answer, I wouldn't want Emacs to assume it can proceed...

 Juanma

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Sun, Apr 13, 2008 at 4:04 PM, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
> 
>>  I would expect that the message sent to the Emacs when clicking on the
>> upper left [X] would terminate any loop, just like C-g terminates a loop in
>> a command.
> 
> keyboard-quit's function is to signal a `quit' condition, so it does it.
> 
> Clicking the upper left [X] sends a WM_CLOSE message to Emacs, which
> tells it to do an orderly exit. That includes executing Lisp code, and
> potentially doing a lot of things: writing files, asking the user,
> killing subprocesses, etc. If some of these things take forever, how
> it is Emacs to know that it is a bug and not expected behavior? For
> example, if something in kill-emacs-query-functions asks me and I
> don't answer, I wouldn't want Emacs to assume it can proceed...

Yes, those are good points, but I think you are perhaps missing my 
point: That WM_CLOSE should be treated more like qiut.

That does not prevent Emacs from asking the type of question you mentioned.

Re: Emacs does not listen on w32

[Juanma Barranquero]

>  Yes, those are good points, but I think you are perhaps missing my point:
> That WM_CLOSE should be treated more like qiut.
>
>  That does not prevent Emacs from asking the type of question you mentioned.

I think you missed my point: how? Either you want [X] to forcefully
abort Emacs, or do you want it to go the orderly exit route, and in
the second case, it has *no way* to know beforehand what should be
run, how much to wait, etc. *Anything* can run in an orderly exit.
There's no guidelines which say that 10 seconds or 20 or a thousand
are OK, and afterwards Emacs is hanged up. What you want would imply
creating a way to specify how to deal with delays in exiting, which is
a can of worms.

 Your C-g example does not apply: that's a user order to abort
something. Clicking in [X] is an order to exit Emacs, not to abort
everything after a while.

What do you want to do is not to close Emacs, but to invoke tskill.exe
or use the task manager to end the process.

 Juanma

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
>  Your C-g example does not apply: that's a user order to abort
> something. Clicking in [X] is an order to exit Emacs, not to abort
> everything after a while.

I think that is wrong. Those too cases should be treated similarly as 
far as possible.

Re: Emacs does not listen on w32

[Juanma Barranquero]

>  I think that is wrong. Those too cases should be treated similarly as far
> as possible.

Aha? What would your ideal Emacs do after receving a [X] click?

 Juanma

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
>>  I think that is wrong. Those too cases should be treated similarly as far
>> as possible.
> 
> Aha? What would your ideal Emacs do after receving a [X] click?

That is a very good question. I suppose I would like it to stop current 
activities and then do a normal save-buffers-kill-terminal (ie if this 
is the last frame of course).

Re: Emacs does not listen on w32

[Eli Zaretskii]

> Date: Sun, 13 Apr 2008 17:19:57 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> Cc: Emacs Devel <emacs-devel@gnu.org>,
> 	Stefan Monnier <monnier@iro.umontreal.ca>, Jason Rumney <jasonr@gnu.org>
> WM_CLOSE should be treated more like qiut.

Other Windows GUI applications do not behave like that: they will ask
you whether to save unsaved changes etc.  Also, an application that is
stuck in an unresponsive situation will not react to the click on the
[X] button, but will instead cause the OS to display the "program is
not responding" dialog.

I don't think Emacs should break all these user expectations about GUI
program's behavior.

Re: Emacs does not listen on w32

[Juanma Barranquero]

On Sun, Apr 13, 2008 at 6:20 PM, Eli Zaretskii <eliz@gnu.org> wrote:

>  I don't think Emacs should break all these user expectations about GUI
>  program's behavior.

Exactly so.

 Juanma

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Sun, 13 Apr 2008 17:19:57 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> Cc: Emacs Devel <emacs-devel@gnu.org>,
>> 	Stefan Monnier <monnier@iro.umontreal.ca>, Jason Rumney <jasonr@gnu.org>
>> WM_CLOSE should be treated more like qiut.
> 
> Other Windows GUI applications do not behave like that: they will ask
> you whether to save unsaved changes etc.

Well, that is what I wanted WM_CLOSE to do, of course. I just want one 
additional thing first: break out of any loop that makes it impossible 
to exit Emacs in the normal way.

> Also, an application that is
> stuck in an unresponsive situation will not react to the click on the
> [X] button, but will instead cause the OS to display the "program is
> not responding" dialog.

If that happens this is a bug in the program. The next step is that 
Windows offers to send a copy of the memory etc to Microsoft.

> I don't think Emacs should break all these user expectations about GUI
> program's behavior.

Hm. You can't mean that users on w32 are used to buggy programs and that 
therefore Emacs also should have a similar bug? ;-)

Re: Emacs does not listen on w32

[Juanma Barranquero]

On Sun, Apr 13, 2008 at 10:49 PM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

>  Well, that is what I wanted WM_CLOSE to do, of course. I just want one
> additional thing first: break out of any loop that makes it impossible to
> exit Emacs in the normal way.

How will you make Emacs differentiate between a loop that is a doing
valid, useful work, and another one that "makes it impossible to exit
Emacs in a normal way"?

 Juanma

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Sun, Apr 13, 2008 at 10:49 PM, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
> 
>>  Well, that is what I wanted WM_CLOSE to do, of course. I just want one
>> additional thing first: break out of any loop that makes it impossible to
>> exit Emacs in the normal way.
> 
> How will you make Emacs differentiate between a loop that is a doing
> valid, useful work, and another one that "makes it impossible to exit
> Emacs in a normal way"?

By recognizing that it has recieved WM_CLOSE. I tried to say that this 
should be handled as a kind of "quit" in those cases.

Re: Emacs does not listen on w32

[Juanma Barranquero]

On Sun, Apr 13, 2008 at 11:04 PM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

>  By recognizing that it has recieved WM_CLOSE. I tried to say that this
> should be handled as a kind of "quit" in those cases.

Why should clicking into the [X] box interrupt useful work without
asking? What will you do if some code in one of `kill-emacs-hook' or
`kill-emacs-query-functions' loops forever? (They would run *after*
your "quitting behavior" was done, IIUC what you're saying.)

 Juanma

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Sun, Apr 13, 2008 at 11:04 PM, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
> 
>>  By recognizing that it has recieved WM_CLOSE. I tried to say that this
>> should be handled as a kind of "quit" in those cases.
> 
> Why should clicking into the [X] box interrupt useful work without
> asking?

It is the user that is clicking the [X]. Maybe there should be a 
question if the the ongoing work should be interrupted though.

> What will you do if some code in one of `kill-emacs-hook' or
> `kill-emacs-query-functions' loops forever? (They would run *after*
> your "quitting behavior" was done, IIUC what you're saying.)

I do not know what can be done in those circumstances, but I guess that 
the window and message framework is still there. (This depends on 
exactly how the exit is implemented.) In that case I would think it is 
best to interrupt that loop to.

Re: Emacs does not listen on w32

[Juanma Barranquero]

On Sun, Apr 13, 2008 at 11:15 PM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

>  I do not know what can be done in those circumstances, but I guess that the
> window and message framework is still there. (This depends on exactly how
> the exit is implemented.) In that case I would think it is best to interrupt
> that loop to.

You have not yet answered my previous question: how do you
differentiate between useful work, and looping forever? With a
timeout?

 Juanma

Re: Emacs does not listen on w32

[David Kastrup]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> Juanma Barranquero wrote:
>> On Sun, Apr 13, 2008 at 11:04 PM, Lennart Borgman (gmail)
>> <lennart.borgman@gmail.com> wrote:
>>
>>>  By recognizing that it has recieved WM_CLOSE. I tried to say that this
>>> should be handled as a kind of "quit" in those cases.
>>
>> Why should clicking into the [X] box interrupt useful work without
>> asking?
>
> It is the user that is clicking the [X]. Maybe there should be a
> question if the the ongoing work should be interrupted though.

If I have two frames, and start some calc command in one frame, then
click [X] on another frame, I don't want the calculation to stop.  If
Emacs can't close the frame "out of processing order" then I'll just
have to wait for the calculation to finish, or stop it manually.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Sun, Apr 13, 2008 at 11:15 PM, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
> 
>>  I do not know what can be done in those circumstances, but I guess that the
>> window and message framework is still there. (This depends on exactly how
>> the exit is implemented.) In that case I would think it is best to interrupt
>> that loop to.
> 
> You have not yet answered my previous question: how do you
> differentiate between useful work, and looping forever? With a
> timeout?


I tried to answer it by saying that if Emacs recieves WM_CLOSE (or 
something similar on other platform) then the user has decided to exit 
Emacs.

But you have a point. I guess it would be reasonable to ask the user if 
the ongoing work should be quitted before exiting.

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

David Kastrup wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>> Juanma Barranquero wrote:
>>> On Sun, Apr 13, 2008 at 11:04 PM, Lennart Borgman (gmail)
>>> <lennart.borgman@gmail.com> wrote:
>>>
>>>>  By recognizing that it has recieved WM_CLOSE. I tried to say that this
>>>> should be handled as a kind of "quit" in those cases.
>>> Why should clicking into the [X] box interrupt useful work without
>>> asking?
>> It is the user that is clicking the [X]. Maybe there should be a
>> question if the the ongoing work should be interrupted though.
> 
> If I have two frames, and start some calc command in one frame, then
> click [X] on another frame, I don't want the calculation to stop.  If
> Emacs can't close the frame "out of processing order" then I'll just
> have to wait for the calculation to finish, or stop it manually.

But if you have two frames and click [X] then Emacs does not want to 
exit so this problem should not occur then. (There will be no WM_CLOSE.)

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Lennart Borgman (gmail) wrote:
> David Kastrup wrote:
>> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
>>
>>> Juanma Barranquero wrote:
>>>> On Sun, Apr 13, 2008 at 11:04 PM, Lennart Borgman (gmail)
>>>> <lennart.borgman@gmail.com> wrote:
>>>>
>>>>>  By recognizing that it has recieved WM_CLOSE. I tried to say that 
>>>>> this
>>>>> should be handled as a kind of "quit" in those cases.
>>>> Why should clicking into the [X] box interrupt useful work without
>>>> asking?
>>> It is the user that is clicking the [X]. Maybe there should be a
>>> question if the the ongoing work should be interrupted though.
>>
>> If I have two frames, and start some calc command in one frame, then
>> click [X] on another frame, I don't want the calculation to stop.  If
>> Emacs can't close the frame "out of processing order" then I'll just
>> have to wait for the calculation to finish, or stop it manually.
> 
> But if you have two frames and click [X] then Emacs does not want to 
> exit so this problem should not occur then. (There will be no WM_CLOSE.)

Eh, that was wrong. I have forgotten how it work, I thought there was a 
special message for exiting. But if I am right now sending WM_CLOSE to 
the last window/frame means "exit application" in w32 message language.

BTW, I just saw that there is an API IsHungAppWindow that considers the 
application hung if it has not called PeedMessage the last 5 seconds.

Re: Emacs does not listen on w32

[Eli Zaretskii]

> Date: Sun, 13 Apr 2008 22:49:22 +0200
> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
> CC: lekktu@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, 
>  jasonr@gnu.org
> 
> > Also, an application that is
> > stuck in an unresponsive situation will not react to the click on the
> > [X] button, but will instead cause the OS to display the "program is
> > not responding" dialog.
> 
> If that happens this is a bug in the program. The next step is that 
> Windows offers to send a copy of the memory etc to Microsoft.

No, you misremember.  It just suggests to end the program (i.e. kill
it).

> > I don't think Emacs should break all these user expectations about GUI
> > program's behavior.
> 
> Hm. You can't mean that users on w32 are used to buggy programs and that 
> therefore Emacs also should have a similar bug? ;-)

I meant what I said; I cannot say it any simpler.

And this silly thread blew a tiny issue way out of proportion, and
have exhausted itself quite some time ago; time to end it.

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Eli Zaretskii wrote:
>> Date: Sun, 13 Apr 2008 22:49:22 +0200
>> From: "Lennart Borgman (gmail)" <lennart.borgman@gmail.com>
>> CC: lekktu@gmail.com, emacs-devel@gnu.org, monnier@iro.umontreal.ca, 
>>  jasonr@gnu.org
>>
>>> Also, an application that is
>>> stuck in an unresponsive situation will not react to the click on the
>>> [X] button, but will instead cause the OS to display the "program is
>>> not responding" dialog.
>> If that happens this is a bug in the program. The next step is that 
>> Windows offers to send a copy of the memory etc to Microsoft.
> 
> No, you misremember.  It just suggests to end the program (i.e. kill
> it).

I am afraid I do not. I just tested to be sure. Windows offers to send a 
copy to Microsoft.

>>> I don't think Emacs should break all these user expectations about GUI
>>> program's behavior.
>> Hm. You can't mean that users on w32 are used to buggy programs and that 
>> therefore Emacs also should have a similar bug? ;-)
> 
> I meant what I said; I cannot say it any simpler.
> 
> And this silly thread blew a tiny issue way out of proportion, and
> have exhausted itself quite some time ago; time to end it.

I think you are simply misunderstanding.

Re: Emacs does not listen on w32

[Stefan Monnier]

>> Well, that is what I wanted WM_CLOSE to do, of course. I just want one
>> additional thing first: break out of any loop that makes it impossible to
>> exit Emacs in the normal way.

> How will you make Emacs differentiate between a loop that is a doing
> valid, useful work, and another one that "makes it impossible to exit
> Emacs in a normal way"?

You wouldn't: when the WM_CLOSE message is put into the queue, the
currently running Elisp code would additionally be interrupted
"unconditionally" by setting the quit-flag.

I'm not sure if that'd be the right behavior.  In any case, the first
thing to do is to figure out what *really* happened in the first place.
We don't even know why Emacs didn't respond.  Maybe it has nothing to do
with the processing of WM_CLOSE.


        Stefan

Re: Emacs does not listen on w32

[Juanma Barranquero]

On Mon, Apr 14, 2008 at 3:21 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:

>  You wouldn't: when the WM_CLOSE message is put into the queue, the
>  currently running Elisp code would additionally be interrupted
>  "unconditionally" by setting the quit-flag.

Yes, that's what I think Lennart was suggesting.

>  I'm not sure if that'd be the right behavior.

It certainly doesn't look like such.

> In any case, the first
>  thing to do is to figure out what *really* happened in the first place.
>  We don't even know why Emacs didn't respond.  Maybe it has nothing to do
>  with the processing of WM_CLOSE.

I don't think the problem was related to WM_CLOSE. What you suggested
is much more likely: a memory leak. Windows tends to be *extremely*
unresponsive on low-memory situations.

My answering to Lennart is because he's trying to hack around a
probable bug by pushing for a half-cooked idea, when a combination of
(the Windows equivalent of) kill -9 and gdb would be more appropriate
:)

 Juanma

Re: Emacs does not listen on w32

[Juanma Barranquero]

On Mon, Apr 14, 2008 at 3:38 AM, Juanma Barranquero <lekktu@gmail.com> wrote:

>  >  You wouldn't: when the WM_CLOSE message is put into the queue, the
>  >  currently running Elisp code would additionally be interrupted
>  >  "unconditionally" by setting the quit-flag.
>
>  Yes, that's what I think Lennart was suggesting.

Well, on second thought, no, not really. Lennart was suggesting that
Emacs would *always* be terminated. So after receiving WM_CLOSE, the
current elisp code would be interrupted, normal code associated with
exiting Emacs would be run (kill-emacs-hook, etc.), and that code
would *also* be terminated, in circumstances that Lennart has not yet
fully explained (presumably, with some sort of timer), if necessary.

 Juanma

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
>> In any case, the first
>>  thing to do is to figure out what *really* happened in the first place.
>>  We don't even know why Emacs didn't respond.  Maybe it has nothing to do
>>  with the processing of WM_CLOSE.
> 
> I don't think the problem was related to WM_CLOSE. What you suggested
> is much more likely: a memory leak. Windows tends to be *extremely*
> unresponsive on low-memory situations.

I think you and Stefan are right about the memory problem but that there 
are two different problems. In response to Eli's message I tested a 
simple loop, something like

   (let (x y)
      (while (not x)
	(setq y (current-time-string))
         (when (string= y "something")
	  (setq x t))))

Running this Emacs does not hang the pc, but it still does not answer 
when clicking the [X]. (I could kill it with C-g here though.)

> My answering to Lennart is because he's trying to hack around a
> probable bug by pushing for a half-cooked idea, when a combination of
> (the Windows equivalent of) kill -9 and gdb would be more appropriate
> :)
> 
>  Juanma
> 

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> On Mon, Apr 14, 2008 at 3:38 AM, Juanma Barranquero <lekktu@gmail.com> wrote:
> 
>>  >  You wouldn't: when the WM_CLOSE message is put into the queue, the
>>  >  currently running Elisp code would additionally be interrupted
>>  >  "unconditionally" by setting the quit-flag.
>>
>>  Yes, that's what I think Lennart was suggesting.
> 
> Well, on second thought, no, not really. Lennart was suggesting that
> Emacs would *always* be terminated. So after receiving WM_CLOSE, the
> current elisp code would be interrupted, normal code associated with
> exiting Emacs would be run (kill-emacs-hook, etc.), and that code
> would *also* be terminated, in circumstances that Lennart has not yet
> fully explained (presumably, with some sort of timer), if necessary.

Maybe that is what I did, but that was then a bit unintentionally. ;-)

Did not my latest response to you about this make more sense?

Re: Emacs does not listen on w32

[Juanma Barranquero]

On Mon, Apr 14, 2008 at 8:46 AM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:

>  Did not my latest response to you about this make more sense?

No.I still don't know what you propose to do in such a case.

 Juanma

Re: Emacs does not listen on w32

[grischka]

Lennart Borgman (gmail) wrote:

> I even had to shut off the pc power since I could not get 
> the Windows Task Manager to come up.

You didn't by any chance play with process priority? I've seen 
such thing (not with emacs), the Task Manager still came up, 
but it took several minutes.

--- grischka

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

grischka wrote:
> Lennart Borgman (gmail) wrote:
> 
>> I even had to shut off the pc power since I could not get 
>> the Windows Task Manager to come up.
> 
> You didn't by any chance play with process priority? I've seen 
> such thing (not with emacs), the Task Manager still came up, 
> but it took several minutes.


No unfortunately not.

Re: Emacs does not listen on w32

[Stefan Monnier]

>>> In any case, the first
>>> thing to do is to figure out what *really* happened in the first place.
>>> We don't even know why Emacs didn't respond.  Maybe it has nothing to do
>>> with the processing of WM_CLOSE.
>> 
>> I don't think the problem was related to WM_CLOSE. What you suggested
>> is much more likely: a memory leak. Windows tends to be *extremely*
>> unresponsive on low-memory situations.

> I think you and Stefan are right about the memory problem but that there are
> two different problems. In response to Eli's message I tested a simple loop,
> something like

>   (let (x y)
>      (while (not x)
> 	(setq y (current-time-string))
>         (when (string= y "something")
> 	  (setq x t))))

> Running this Emacs does not hang the pc, but it still does not answer when
> clicking the [X]. (I could kill it with C-g here though.)

Yes, that's perfectly normal.  The current semantics of WM_CLOSE (for
Emacs) is more or less the same as C-x C-c (or C-x 5 0): it waits for
the current command to finish and then runs another command that deletes
the frame.


        Stefan

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Stefan Monnier wrote:
>>>> In any case, the first
>>>> thing to do is to figure out what *really* happened in the first place.
>>>> We don't even know why Emacs didn't respond.  Maybe it has nothing to do
>>>> with the processing of WM_CLOSE.
>>> I don't think the problem was related to WM_CLOSE. What you suggested
>>> is much more likely: a memory leak. Windows tends to be *extremely*
>>> unresponsive on low-memory situations.
> 
>> I think you and Stefan are right about the memory problem but that there are
>> two different problems. In response to Eli's message I tested a simple loop,
>> something like
> 
>>   (let (x y)
>>      (while (not x)
>> 	(setq y (current-time-string))
>>         (when (string= y "something")
>> 	  (setq x t))))
> 
>> Running this Emacs does not hang the pc, but it still does not answer when
>> clicking the [X]. (I could kill it with C-g here though.)
> 
> Yes, that's perfectly normal.  The current semantics of WM_CLOSE (for
> Emacs) is more or less the same as C-x C-c (or C-x 5 0): it waits for
> the current command to finish and then runs another command that deletes
> the frame.

Yes, I know, but I think there are at least two problems here:

- I do not believe this is the right semantics for WM_CLOSE.

- If you run the above code in a timer (like I did) it is worse. There 
is no way at all to stop it. (Except from Task Manager.)

For both these problems I think a change in the semantics for WM_CLOSE 
(and related messages) are the best cure.

For Juanmas very relevant question how this should work I suggest 
something like this:

- Give Emacs say 4 seconds to finish what it is doing. (The 
documentation for IsHungAppWindow says that an application should be 
considered hung if it does not respond in 5 seconds.) If it did not 
finish then ask the user whether to interrupt or not.


BTW, related to this is WM_QUERYENDSESSION which I believe Emacs 
currently does not handle (or even look at).

Re: Emacs does not listen on w32

[Stefan Monnier]

> Yes, I know, but I think there are at least two problems here:

> - I do not believe this is the right semantics for WM_CLOSE.

That's what I gathered from your bug-report -;)

> - If you run the above code in a timer (like I did) it is worse. There is no
> way at all to stop it. (Except from Task Manager.)

This is completely independent from WM_CLOSE and is a much more general
problem: any code run from a timer (or other places that set
inhibit-quit, such as jit-lock) should guarantee that it only runs for
a short time (and/or check input-pending-p, or use with-local-quit.

The core of the problem here is that too many programmers don't know
about it, and that there's no (easy) way to automatically catch code
that doesn't follow those guidelines.

> For both these problems I think a change in the semantics for WM_CLOSE (and
> related messages) are the best cure.

For the second problem, you have to realize that it will bite you in
many more cases than just WM_CLOSE.

> - Give Emacs say 4 seconds to finish what it is doing. (The documentation
> for IsHungAppWindow says that an application should be considered hung if it
> does not respond in 5 seconds.) If it did not finish then ask the user
> whether to interrupt or not.

If you have such an infinite loop within a timer code, then Emacs *is*
hung, and it seems perfectly fine to let the OS's IsHungAppWindow deal
with it.


        Stefan

Re: Emacs does not listen on w32

[Jason Rumney]

Stefan Monnier wrote:
> If you have such an infinite loop within a timer code, then Emacs *is*
> hung, and it seems perfectly fine to let the OS's IsHungAppWindow deal
> with it.
>   

I think Lennart's problem is that we don't let the OS's IsHungAppWindow 
deal with it.  In Windows, each Window must have its own thread for 
message handling.  This thread is not blocked by the infinite loop in 
the Lisp thread, so as far as Windows is concerned, the message has been 
received and dealt with.  We could change the WM_CLOSE message to do a 
blocking SendMessage instead of a non-blocking PostMessage to pass the 
message on to the Lisp thread, but if we decide that the solution we 
want is to let Emacs be forcibly closed after a timeout, it might be 
better to have our own timeout so we can control what message we display 
to the user and at least attempt to quit the Lisp blockage and shutdown 
cleanly rather than letting the system do it uncleanly.

Re: Emacs does not listen on w32

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> BTW, related to this is WM_QUERYENDSESSION which I believe Emacs 
> currently does not handle (or even look at).

It doesn't need to handle it. It registers a shutdown handler, which has 
the additional benefit of working in non-Windowed mode as well.

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> BTW, related to this is WM_QUERYENDSESSION which I believe Emacs 
>> currently does not handle (or even look at).
> 
> It doesn't need to handle it. It registers a shutdown handler, which has 
> the additional benefit of working in non-Windowed mode as well.

Thanks, I did not know about that. Does the shutdown handler take care 
of the WM_QUERYMESSAGE behind the scenes in some way that Emacs can ask 
the user to save data (which the action that message is supposed to 
result in)?

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Stefan Monnier wrote:
>> If you have such an infinite loop within a timer code, then Emacs *is*
>> hung, and it seems perfectly fine to let the OS's IsHungAppWindow deal
>> with it.
>>   
> 
> I think Lennart's problem is that we don't let the OS's IsHungAppWindow 
> deal with it.  In Windows, each Window must have its own thread for 
> message handling.  This thread is not blocked by the infinite loop in 
> the Lisp thread, so as far as Windows is concerned, the message has been 
> received and dealt with.  We could change the WM_CLOSE message to do a 
> blocking SendMessage instead of a non-blocking PostMessage to pass the 
> message on to the Lisp thread, but if we decide that the solution we 
> want is to let Emacs be forcibly closed after a timeout, it might be 
> better to have our own timeout so we can control what message we display 
> to the user and at least attempt to quit the Lisp blockage and shutdown 
> cleanly rather than letting the system do it uncleanly.

I do not understand what you mean here. Does the lisp thread look for 
new messages when it is looping? (I think it should.)

If it does then shouldn't it find a message from PostMessage?

If it does not then we can't do any useful after a SendMessage with 
timeout either, or can we?

Re: Emacs does not listen on w32

[Stefan Monnier]

>> If you have such an infinite loop within a timer code, then Emacs *is*
>> hung, and it seems perfectly fine to let the OS's IsHungAppWindow deal
>> with it.

> I think Lennart's problem is that we don't let the OS's IsHungAppWindow deal
> with it.  In Windows, each Window must have its own thread for message
> handling.  This thread is not blocked by the infinite loop in the Lisp
> thread, so as far as Windows is concerned, the message has been received and
> dealt with.

Oops ;-)

> We could change the WM_CLOSE message to do a blocking SendMessage
> instead of a non-blocking PostMessage to pass the message on to the
> Lisp thread, but if we decide that the solution we want is to let
> Emacs be forcibly closed after a timeout, it might be better to have
> our own timeout so we can control what message we display to the user
> and at least attempt to quit the Lisp blockage and shutdown cleanly
> rather than letting the system do it uncleanly.

If Emacs is truly hung, it's perfectly fine to shutdown uncleanly.
But if C-g works, then it makes sense to do a `quit' so as to interrupt
any long running operation.  But we'd probably first want to wait
a couple seconds and before doing the `quit'.


        Stefan

Re: Emacs does not listen on w32

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> I do not understand what you mean here. Does the lisp thread look for 
> new messages when it is looping? (I think it should.)
It reads the message queue at the normal points where normal keyboard 
input is read (not Ctrl-G, that is handled specially). You have to call 
specific functions in your lisp loop to arrange for it to happen inside 
your loop. You might do that if you expect your loop to take a long 
time, but probably not if it is an infinite loop because of a bug.


> If it does not then we can't do any useful after a SendMessage with 
> timeout either, or can we?

If we used SendMessage, then the system would detect that we aren't 
responding to that message after its timeout.

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> I do not understand what you mean here. Does the lisp thread look for 
>> new messages when it is looping? (I think it should.)
> It reads the message queue at the normal points where normal keyboard 
> input is read (not Ctrl-G, that is handled specially). You have to call 
> specific functions in your lisp loop to arrange for it to happen inside 
> your loop. You might do that if you expect your loop to take a long 
> time, but probably not if it is an infinite loop because of a bug.

Is it necessary to call those specific functions? Can't we use the same 
mechanism that is used for Ctrl-G when WM_CLOSE is recieved? (After a 
timeout of course.)


>> If it does not then we can't do any useful after a SendMessage with 
>> timeout either, or can we?
> 
> If we used SendMessage, then the system would detect that we aren't 
> responding to that message after its timeout.

I see. That is a benefit, but that does not help very much if the goal 
is to give the user a chance to save data (or bring Emacs back to a 
useable state).

Re: Emacs does not listen on w32

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Thanks, I did not know about that. Does the shutdown handler take care 
> of the WM_QUERYMESSAGE behind the scenes in some way that Emacs can 
> ask the user to save data (which the action that message is supposed 
> to result in)?

No, applications are not supposed to ask the user anything during 
shutdown if they can possibly avoid it by doing autosaves.  See the 
previous thread on the subject, and the dire warnings in Microsoft's new 
documentation about the changes they made in Vista to avoid the all too 
common situation where some mystery program prevents your machine 
shutting down by either opening a dialog somewhere where you cannot see 
it, or not opening one at all and telling the system not to shut down at 
this time.

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> Thanks, I did not know about that. Does the shutdown handler take care 
>> of the WM_QUERYMESSAGE behind the scenes in some way that Emacs can 
>> ask the user to save data (which the action that message is supposed 
>> to result in)?
> 
> No, applications are not supposed to ask the user anything during 
> shutdown if they can possibly avoid it by doing autosaves.  See the 
> previous thread on the subject, and the dire warnings in Microsoft's new 
> documentation about the changes they made in Vista to avoid the all too 
> common situation where some mystery program prevents your machine 
> shutting down by either opening a dialog somewhere where you cannot see 
> it, or not opening one at all and telling the system not to shut down at 
> this time.


Sorry, forgot they have changed that recommendation.

Re: Emacs does not listen on w32

[Óscar Fuentes]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

>> Yes, that's perfectly normal.  The current semantics of WM_CLOSE (for
>> Emacs) is more or less the same as C-x C-c (or C-x 5 0): it waits for
>> the current command to finish and then runs another command that deletes
>> the frame.
>
> Yes, I know, but I think there are at least two problems here:
>
> - I do not believe this is the right semantics for WM_CLOSE.
[snip]

WM_CLOSE just indicates that a window or application *should*
terminate. From the Windows POV, not obeying that message does not
indicate a bug. It just means that the app decided that closing the
window or application was not appropiate.

[snip]

-- 
Oscar

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Óscar Fuentes wrote:
> "Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:
> 
>>> Yes, that's perfectly normal.  The current semantics of WM_CLOSE (for
>>> Emacs) is more or less the same as C-x C-c (or C-x 5 0): it waits for
>>> the current command to finish and then runs another command that deletes
>>> the frame.
>> Yes, I know, but I think there are at least two problems here:
>>
>> - I do not believe this is the right semantics for WM_CLOSE.
> [snip]
> 
> WM_CLOSE just indicates that a window or application *should*
> terminate. From the Windows POV, not obeying that message does not
> indicate a bug. It just means that the app decided that closing the
> window or application was not appropiate.
> 
> [snip]

Does not that depend on the situation? If Windows is shutting down then 
I think the app should terminate (or perhaps ask, but that is a bad 
choice according to what Jason pointed out).

Re: Emacs does not listen on w32

[Óscar Fuentes]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

>> WM_CLOSE just indicates that a window or application *should*
>> terminate. From the Windows POV, not obeying that message does not
>> indicate a bug. It just means that the app decided that closing the
>> window or application was not appropiate.
>>
>> [snip]
>
> Does not that depend on the situation? If Windows is shutting down
> then I think the app should terminate

When Windows shuts down, it sends the WM_ENDSESSION message with wParam
set to TRUE. The application must do its terminatin stuff before
returning from this message.

> (or perhaps ask, but that is a bad choice according to what Jason
> pointed out).

That's what WM_QUERYENDSESSION.

All this info comes from old SDK docs. Maybe it changed for Vista.


-- 
Oscar

Re: Emacs does not listen on w32

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> Does not that depend on the situation? If Windows is shutting down 
> then I think the app should terminate (or perhaps ask, but that is a 
> bad choice according to what Jason pointed out).

As I already pointed out, shutdown is handled elsewhere.

Re: Emacs does not listen on w32

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> Does not that depend on the situation? If Windows is shutting down 
>> then I think the app should terminate (or perhaps ask, but that is a 
>> bad choice according to what Jason pointed out).
> 
> As I already pointed out, shutdown is handled elsewhere.

Sorry for mixing things up. It was clearly a mistake by my to mention 
technical details at all at this stage. Back to the problem:

- Emacs is looping in a timer (fontification). There is no way to stop 
it from looping that I can think of. I can't even stop Emacs.

The basic problem to solve is really to stop Emacs from looping in the 
timer. I think there should be a way to do that. I can't see that there 
is any now. Am I wrong?

(If there is a way to stop Emacs from looping then I think that should 
be used when exiting Emacs, but I leave that out for now since it seemed 
difficult to have a reasonable discussion otherwise.)