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.