[usocket-devel] Status of UDP on Windows?

Elliott Slaughter elliottslaughter at gmail.com
Tue Mar 23 06:12:25 UTC 2010


On Mon, Mar 22, 2010 at 5:18 PM, Elliott Slaughter <
elliottslaughter at gmail.com> wrote:

> 2010/3/22 Chun Tian (binghe) <binghe.lisp at 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.

Thoughts?

-- 
Elliott Slaughter

"Don't worry about what anybody else is going to do. The best way to predict
the future is to invent it." - Alan Kay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/usocket-devel/attachments/20100322/e919add1/attachment.html>


More information about the usocket-devel mailing list