[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: LuaSocket, Win32 and select()
- From: David Burgess <dburgess@...>
- Date: Tue, 25 Jan 2005 22:18:23 +1000
Donald,
On behalf of a busy Diego (I am sure he will answer you later).
> Assuming that one is happy with 100s of connections at a time, then it
> seems than plain old Lua coroutines with plain old LuaSocket 2 are just
> the ticket.
Yep!
> >Important note: a known bug in WinSock causes select to fail on
> >non-blocking TCP sockets. The function may return a socket as
> >writable even though the socket is not ready for sending.
>
> This still true in "recent" Windowses, e.g. 2000 SP4, 2003, XP SP1/2?
If its the bug I know, yes.
MS say its a feature. Cutting from the waseventselect doco (they dont say it
for select() anymore):
<quote>
As in the case of the select and WSAAsyncSelect functions,
WSAEventSelect will frequently be used to determine when a data
transfer operation (send or recv) can be issued with the expectation
of immediate success. Nevertheless, a robust application must be
prepared for the possibility that the event object is set and it
issues a Windows Sockets call that returns WSAEWOULDBLOCK immediately.
For example, the following sequence of operations is possible:
Data arrives on socket s; Windows Sockets sets the WSAEventSelect event object.
The application does some other processing.
While processing, the application issues an ioctlsocket(s,
FIONREAD...) and notices that there is data ready to be read.
The application issues a recv(s,...) to read the data.
The application eventually waits on the event object specified in
WSAEventSelect, which returns immediately indicating that data is
ready to read.
The application issues recv(s,...), which fails with the error WSAEWOULDBLOCK
</quote>
The same happens on writable with both connect() and send(). I have also
seen this on other socket implemntations.
DB