Re: PLEASE TEST: New implementation of blocking socket I/O

[Christopher Faylor <cgf at alum dot bu dot edu>]

On Thu, Apr 01, 2004 at 06:11:37PM +0200, Corinna Vinschen wrote:
>On Apr  1 10:04, Pierre A. Humblet wrote:
>> You are right. But now I have a question. Is it possible for WSASendTo
>> to send some data (i.e. ret > 0) and also return SOCKET_ERROR and set
>> WSAEWOULDBLOCK (because it can't send everything)? If not, the test 
>> if (ret > 0) {  ...; break; } is useless (*).
>
>Yes, it is possible, therefore the test.  WSASendTo returns always
>immediately as long as it can push the data to the service providers
>buffer space.  If only partial buffer space is available, it returns
>the number of transmitted bytes and returns WSAEWOULDBLOCK.  At least
>this is how I understand MSDN.
>
>> Another related question: is it necessary to create/delete an event for
>> each call, or could a single event be reused in all calls. Or perhaps
>> one event for write and one for read (and close in both, or a third one
>> for close)?
>
>No that doesn't work.  You can always have only one active WSAEventSelect
>or WSAAsyncSelect.  Any call to one of these functions override a former
>call.  Therefore it would be possible to keep an event object open all
>the time, but the WSAEventSelect would nevertheless have to be called to
>switch to the correct set of network events.  Having an event object open
>all the time would be a possible speed up, but for now I'd be happy to
>get it working.
>
>> > I've also applied the following:  If the FD_CLOSE event is recognized,
>> > then ret is set to 0 only if wsa_err is still 0.  Otherwise it would
>> > have been possible that even in case an error has happened, the function
>> > returns 0.
>> 
>> Will try again tonight.
>
>Thanks.
>
>> > Hmm 2.  That really stumps me.  Is it possible that WSARecvFrom receives
>> > partial data, sets ret to a value > 0 and nevertheless returns WSAEWOULDBLOCK?
>> 
>> What happens if there is already data in the buffer when the event
>> is created? Will it be set then, or when more data arrives (if ever ?).
>> In other words isn't it better to try reading before waiting?
>
>Hmmmmmmm, that's a good question.  Always try reading and only if that
>fails with WSAEWOULDBLOCK, call wait?  That would make the loop more
>similar to the way the send loop works, where that's absolutely necessary.
>
>[time passes reading MSDN over and over again]
>
>Bingo!  That might be it.  MSDN states "Issuing a WSAEventSelect for a
>socket cancels any previous WSAAsyncSelect or WSAEventSelect for the
>same socket and clears the internal network event record."
>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>		!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>
>I'll change the Recv loop accordingly.  You'll probably see a patch on
>cygwin-cvs in a while.
>
>> > > Perhaps you would have more luck triggering this bug if
>> > > you tried a low speed (modem) connection.
>> > 
>> > I don't even own a modem.
>> 
>> I didn't know you could even buy a machine without a modem.
>
>Well, you're right, I just found out that I have some AC97 on-board
>modem.  But I have a ISDN/DSL combo, so it doesn't work for me.
>
>> I don't mind spending a few more hours on this. I wish other people
>> would also report the problem! However if this gets in the way of
>
>Yes, I'm wondering if all other 37 subscribers to cygwin-developers
>are somehow dropped dead under the table or so.  
>
>GUYS, WAKE UP!  It's not that *that* hard to debug Cygwin.
>
>> 1.5.10 I would revert, at least temporarily.
>
>If Chris would want to release 1.5.10, I could revert to overlapped
>I/O plus Patrick Samson's suggestion from the Cygwin ML within an
>hour.  So, no worries.

I'm not going to release cygwin with the cygheap problem.  See your
comment above about the 37 other subscribers.

I'm a little preoccupied with job switching right now so my time for
debugging is limited.  Heh, heh, heh.

cgf