On Mon, Mar 22, 2010 at 11:12 PM, Elliott Slaughter <elliottslaughter@gmail.com> wrote:
On Mon, Mar 22, 2010 at 5:18 PM, Elliott Slaughter <elliottslaughter@gmail.com> wrote:2010/3/22 Chun Tian (binghe) <binghe.lisp@gmail.com>Strange ... for long time I thought there's no "select()" on win32, and I do see Erik (USOCKET author) use "WSAEventSelect" to implement the LispWorks version of WAIT-FOR-INTPUT-INTERNAL on win32. Now it seems that I was confused by another the speciality of "select()" function on win32:
* On UNIX, select() can be used to wait for both networking sockets and disk file handlers,
* On Windows, select() can only be used on networking sockets, so it's implemented by winsock library.
What you found, seems show me a very direct way to have all you want done immediately: just use SB-ALIEN to export the "select()" for win32, and remove the reader macro around exist Unix version of WAIT-FOR-INPUT-INTERNAL for SBCL.
Would you like a try on this approach?I'll give it a shot.I've got a couple of updates:
First, sbcl/win32 apparently includes sb-unix, which means that the existing implementation of wait-for-input-internal which calls sb-unix:unix-fast-select works without modification on sbcl/win32.That said, it doesn't seem to work correctly: in my tests, wait-for-input returns immediately even when no input is available, causing my call to socket-receive to block. This happens for any value of timeout, including nil, 0, and non-zero values.I even replaced the call to sb-unix:unix-fast-select to a hand-coded call to winsock's select via sb-alien, and got exactly the same result. No errors are produced, select just returns that the socket is ready when it is not actually ready.I'm not sure what could be causing this to happen, and I don't see anything in the documentation indicating that select would return a socket which would block on a call to recvfrom (which is what sb-bsd-sockets seems to be calling internally). Google has not provided any helpful answers.