PROBLEM: recvfrom is not resetting FD_READ event set with WSAEventSelect.
PLATFORM: Windows 2000 Advanced Server, Build 2195
SPECIFICS:
Socket specs:
-PF_INET (TCP/IP)
-SOCK_DGRAM (UDP)
-SO_BROADCAST
Read Loop:
-Create event using WSACreateEvent
-Register for FD_READ event using WSAEventSelect
-Enter loop
-Wait on event
-Issue a recvfrom to get data*
-Loop
*this should reset read event (if no data, which there is not), but does not
so future invocations return WSAWOULDBLOCK and the loop runs infinitely
eating up the CPU.
Miscellaneous:
-Packet that is received is sent from the same machine.
-If I use an auto reset event it appears to work okay, but this should not
be necessary according to docs (plus what if condition is still true, would
have to wait for next packet before processing previous data then)
-Same socket is used for both sends and receives (Tried using different one
as well, no luck)
I have used this same algorithm before under NT 4.0 and it seemed to work
fine. I would appreciate it if someone can confirm this as a bug or if
there is something I am doing incorrectly. Thanks…
Scott Meeuwsen
High Level Software, Ltd.
Update: After rereading the docs it appears I made the mistake of
associating “reenabling” with “resetting”. However, it isn’t very clear.
Do I need to reset the event manually even though I am calling a
“reenabling” function? Thanks.
Scott Meeuwsen
High Level Software, Ltd.
----- Original Message -----
From: “Scott Meeuwsen”
To: “NT Developers Interest List”
Sent: Tuesday, April 04, 2000 11:43 AM
Subject: [ntdev] Winsock2 woes… (Possible bug?)
> PROBLEM: recvfrom is not resetting FD_READ event set with WSAEventSelect.
> PLATFORM: Windows 2000 Advanced Server, Build 2195
> SPECIFICS:
>
> Socket specs:
> -PF_INET (TCP/IP)
> -SOCK_DGRAM (UDP)
> -SO_BROADCAST
>
> Read Loop:
> -Create event using WSACreateEvent
> -Register for FD_READ event using WSAEventSelect
> -Enter loop
> -Wait on event
> -Issue a recvfrom to get data*
> -Loop
>
> *this should reset read event (if no data, which there is not), but does
not
> so future invocations return WSAWOULDBLOCK and the loop runs infinitely
> eating up the CPU.
>
> Miscellaneous:
> -Packet that is received is sent from the same machine.
> -If I use an auto reset event it appears to work okay, but this should not
> be necessary according to docs (plus what if condition is still true,
would
> have to wait for next packet before processing previous data then)
> -Same socket is used for both sends and receives (Tried using different
one
> as well, no luck)
>
> I have used this same algorithm before under NT 4.0 and it seemed to work
> fine. I would appreciate it if someone can confirm this as a bug or if
> there is something I am doing incorrectly. Thanks…
>
> Scott Meeuwsen
> High Level Software, Ltd.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@highlevel.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
>