The BUGS file says:
> 421: READ-CHAR-NO-HANG misbehaviour on Windows Console:
> It seems that on Windows READ-CHAR-NO-HANG hangs if the user
> has pressed a key, but not yet enter (ie. SYSREAD-MAY-BLOCK-P
> seems to lie if the OS is buffering input for us on Console.)
> reported by Elliot Slaughter on sbcl-devel 2008/1/10.
Supposedly, this is hindering the use of SLIME on Win32.
The actual problem is more likely related to the complete lack of
support for non-pipe, non-console HANDLEs in SB-WIN32:HANDLE-LISTEN.
Those who have looked into this have no doubt noticed the FIXME comment
in the definition for this function about using WSAEventSelect. Adding
support for this is not quite so straightforward as we might like, as
using WSAEventSelect means that we need to check for input events on a
different HANDLE object than we read and write from, breaking a
fundamental assumption of SERVE-EVENT, and requiring a hack of some sort
to override the default mapping of file descriptors to handles.
Additionally, there are two complications with reading from a network
socket that is using WSAEventSelect. First, the event needs to be
cleared prior to reading, so as to report the correct state after the
read is performed. Second, to properly support the case of attempting
to read from a socket with insufficient data, it is necessary to use
recv instead of read and translate the one error case corresponding to
A proof-of-concept implementation of these changes and an implementation
of SUB-SERVE-EVENT using Win32 APIs instead of the select() emulation
wrapper (necessary to make the hack for using a different handle for a
file descriptor work), including a hook to support handling window
messages from SERVE-EVENT is available at
<http://www.lisphacker.com/temp/new-serve-event.lisp>. This has been
tested with SBCL-18.104.22.168, Cygwin emacs 22.2.1, and SLIME 2007-09-27
with the fd-handler communication-style, and works, including the window
message hook. This hack is not in good style, but at least demonstrates
the basic idea.