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

["Pierre A. Humblet" <Pierre dot Humblet at ieee dot org>]

Corinna Vinschen wrote:
> 
> On Mar 31 22:06, Pierre A. Humblet wrote:
> > At 05:36 PM 3/31/2004 +0200, Corinna Vinschen wrote:
> > >There's a chance that the first call to WSAwhatever already returns
> > >WSAEWOULDBLOCK and ret is uninitialized.  I've applied a fix which
> > >always set ret to 0 in calls to WSAwhatever.  Does that help?
> >
> > It makes a difference, but I am not sure why, it shouldn't be necessary
> > AFAICS.
> 
> When calling WSASendTo for the first time, ret was uninitialized.  If
> WSASendTo returns with WSAEWOULDBLOCK and ret hasn't been touched, the
> weird result could have occured.  But you're right.  In theory, WSASendTo
> should always set ret to a useful value.  In theory...

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 (*).
 
> Thanks for catching.  I've checked in a patch to wsock_event::release
> which saves the last error and restores it at the end, if not ioctlsocket
> fails, in which case I return that error.  I'm not quite sure if that's
> exactly right but I think the ioctlsocket error would have some weight.
> I also removed the destructor entirely.

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)?

> 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.
 
> > No luck, wsock errno is still 0, but sendmsg surely fails.
> 
> Hmm.
> 
> > And yes, from time to time it does like in my first report, hanging
> >   158 2552618 [main] cvs 540017 readv: readv (4, 0x7DEBC0, 1) blocking,
> > sigcatchers 6
> >   154 2552772 [main] cvs 540017 readv: no need to call ready_for_read
> 
> 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?

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

> Thanks for debugging, btw.  However, I'm wondering if I should revert
> to overlapped I/O.  While the async I/O code looks pretty simple, it
> seems I opened the box of Pandora.  Sigh.

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
1.5.10 I would revert, at least temporarily.
Is there any chance 1.5.10 will come out within a week? Otherwise
I will send some other patches now.

Pierre