emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel Colascione
Subject: Re: [PATCH] system-type cygwin with window-system w32
Date: Mon, 18 Jul 2011 10:50:37 -0700
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0

On 7/18/11 10:33 AM, grischka wrote:
> Daniel Colascione wrote:
>> I'll have to add a comment explaining what's going on here.  In the
>> meantime: the main thread doesn't usually pump messages because it's
>> blocked on select(2) instead.  
> 
> Doesn't cygwin have a pseudo device /dev/windows to select for
> incoming WM_xxx messages?
> 
> --- grischka

Wow.  Thanks for the tip.  /dev/windows doesn't appear to be well-documented
externally, but from fhandler_windows.cc in the Cygwin tree:

/*
The following unix-style calls are supported:

        open ("/dev/windows", flags, mode=0)
                - create a unix fd for message queue.

        read (fd, buf, len)
                - return next message from queue. buf must point to MSG
                  structure, len must be >= sizeof (MSG). If read is set to
                  non-blocking and the queue is empty, read call returns -1
                  immediately with errno set to EAGAIN, otherwise it blocks
                  untill the message will be received.

        write (fd, buf, len)
                - send a message pointed by buf. len argument ignored.

        ioctl (fd, command, *param)
                - control read()/write() behavior.
                ioctl (fd, WINDOWS_POST, NULL): write() will PostMessage();
                ioctl (fd, WINDOWS_SEND, NULL): write() will SendMessage();
                ioctl (fd, WINDOWS_HWND, &hWnd): read() messages for
                        hWnd window.

        select () call marks read fd when any message posted to queue.
*/


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.

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.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]