Re: [PATCH] system-type cygwin with window-system w32

[Daniel Colascione <dan.colascione@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3552 bytes --]

On 7/18/2011 11:38 AM, grischka wrote:
> Daniel Colascione wrote:
>> If it works, /dev/windows would allow us to get rid of not only the
>> self-pipe
>> and the clipboard thread, but the UI thread as well, though it'd be
>> easier to
>> keep the last of these for compatibility for the NT build.  Thanks.
>
> Actually the NT build works quite well with one single thread.
> Already tested here.

Do you have a patch handy?

>> By the way: why do we use a separate UI thread in the NT case at all?
>> AIUI, we
>> can do everything we need asynchronously via overlapped IO, so we
>> should never
>> have to block and not pump messages.
>
> The 'sys_select' wrapper DOES pump messages, just for the wrong
> thread.  So it needs the thread because it has the thread. :)

Of course.  I suspect the initial motivation behind the separate thread
is a long, somnolent story involving QUIT.

> Well, there are two other things needed:
> * 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.

Actually, on that note, I should add a timeout to my WM_RENDERFORMAT
code: we shouldn't block other applications forever merely because Emacs
is spinning in Lisp.

> * 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.

On 7/18/2011 11:52 AM, grischka wrote:
> Daniel Colascione wrote:
>> This requirement is incompatible
>> with using lisp code to render clipboard content: we might have
>> received a
>> window message at an inopportune time for calling back into Lisp, and
>> we can't
>> delay the response to WM_RENDERFORMAT by re-queuing or somesuch. 
>> Today's NT
>> clipboard code doesn't have to address the issue because it never
>> calls into Lisp.
> 
> Well, you can do this if you have a function to pump elisp
> events, say drain_lisp_queue():
> 
> That would be basically command_loop_1() with
>     while (1)
> replaced by
>     while (detect_input_pending())
> 
> Then, in window_proc:
>     case WM_RENDERFORMAT:
>         queue_lisp_event(); //I guess it's "kbd_buffer_store_event_hold"
>         drain_lisp_queue();
>         break;
> 
> Or such.
> 

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.

[1] http://blogs.msdn.com/b/oldnewthing/archive/2006/02/10/529525.aspx


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 258 bytes --]