Daniel Colascione wrote:
>> Actually the NT build works quite well with one single thread.
>> Already tested here.
> 
> Do you have a patch handy?

Attached.  Patch was against state at commit:

       Jan D. <jan.h.d@swipnet.se>  2011-02-01 09:53:03
       Use add/delete_read_fd in xsmfns to simplify.  Also ...

Hopefully still applies cleanly.

It is minimal, and maybe not quite obvious.  Basically the two window
message switches (w32fns.c and w32term.c) could be merged into one.
The patch calls the one from the other.

There is an elisp variable 'w32-single-thread' which should return 1
if you want to make sure you're using the right build. :)

Note that you can for example drag the "Open File" dialog across the
main window and it still gets redrawn.

>> * peek for messages in the QUIT macro (say via ELSE_PENDING_SIGNALS)
>>   which is for C-g to interrupt lisp.
> 
> I don't think this approach alone would be sufficient.  I may be wrong,
> but I think the Windows window manager will consider a program to be
> "unresponsive" if it stops actually pumping messages; I don't think
> peeking is sufficient.  Also, [1] says that we shouldn't delay pumping
> messages even if we're able to guarantee we'll get around to them later.
> (Running lisp code is indistinguishable from sleep in this case.)

> Using PeekMessage in lisp code instead of actually pumping messages
> would be like telling your credit card company, "Yeah, I got the bill,
> and I'll get around to responding sometime in the next two years".  I
> don't think it'd go over well.

"Two years" or anyway "indistinguishable from sleep" is never really
acceptable.  Because then emacs can't process key/mouse events
regardless how many threads you have in the backend.

We need to think in terms of UI timings here.  Reference is the kbd
repeat rate, say 30ms, which is also in the range of eye perception
capability and frame repeat rates.  Up to this is smooth.  More can
be tolerable though, even up to 1 or more seconds.  Say for popping
up new windows, frames, etc.

So if your elisp doesn't finish in 30ms, you know ;)

>> * break command_loop_1() such that it can be used to handle just one
>>   event which is to handle scrollbar messages because the widgets
>>   run their own message loop deep in windows.  Otherwise all the
>>   scrolling would happen only after you release the mouse button.
> 
> I doubt that the scrollbar is the only special case we'd need to consider.

AFAICS scrollbar and paint. And maybe clipboard rendering.  Emacs
handles paint directly via expose_frame() though, not via the event
queue.

> I don't understand how this approach helps.  The problem, AIUI, isn't
> that we have Lisp events, but that we read input and wait for processes
> in many places, and it's hard to be confident that each place we pump
> messages is a safe place to process lisp code.  I don't understand how
> draining the lisp event queue would help.

As I see it this is just recursion.   Such things happen all the time
in all GUIs that use callbacks.  Windows, GTK, whatever.  It happens
in emacs already:

       (run-with-idle-timer ... lisp-code)

--- grischka