PLEASE TEST: New implementation of blocking socket I/O

Corinna Vinschen
Thu Apr 1 16:11:00 GMT 2004

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.


> > 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.

> Is there any chance 1.5.10 will come out within a week? Otherwise
> I will send some other patches now.

AFAICS, we have currently three pressing problems:

- People complaining about cygheap problems (Win32 error 487) but
  nobody willing to debug it.

- Async vs. Overlapped socket I/O.

- The failing shmat problem under XWin, which should be solved in CVS
  but hasn't been tested so far.

I'd wish to release 1.5.10 soon but especially due to the first problem
it doesn't look like that will happen.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                      
Red Hat, Inc.

More information about the Cygwin-developers mailing list