Re: [reSIProcate] TCP Behavior - on Windows at least...

[Alan Hawrylyshen <alan@xxxxxxxxxx>]

On Apr 21, 2005, at 11.18, Scott Godin wrote:

> For some reason fdset.readyToReady is returning TRUE, but then
> currConnection->read is returning WSAWOULDBLOCK.  Therefore resip 
> tears down
> the socket connection.  I suspect the problem is Windows related.  Are 
> you
> using windows at all?
>
> I'm still digging (trying to understand why readyToRead is returning 
> true),
> so any help or suggestions would be appreciated.
>
> Thanks,
>
> Scott

Hmm.
We use TCP on windows too.  I think you are on the right track in 
wondering why readToRead is T, but you get the equivalent of 
EWOULDBLOCK.  It is likely well worth the effort to hunt down the 
readToRead problem 1st.  Have we accidentally set the NONBLOCK mode on 
the socket (and this is acting up under Win32)?  With a better 
understanding around why readyToRead is lying to us ;-) we can likely 
fix this.  The horrid unrecommended hack would be to ignore EWOULDBLOCK 
(WSAWOULDBLOCK) errors, but then we risk being stuck in an infinite 
busy wait while we hang out. Is it possible that your process was 
delivered a signal or message that caused the select/poll/epoll event 
to break-out and this is normal behaviour. IOW, just consider adding 
logic to ignore the WSAWOULDBLOCK error and restart the wait.
If you can determine (and prove with docs) that this is what's 
happening, then it is likely just a case in the code that we didn't 
consider.

This can happen in UNIX systems if you forget to deal with SIGALRM 
properly. Your select exits and tells you things that aren't true.


Alan

a l a n a t j a s o m i d o t c o m