Re: BUG in Winsock on P4 HT CPU

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: stuart blemcan (stuart_at_nospam.com)
Date: 08/19/04


Date: Thu, 19 Aug 2004 10:28:02 -0700

i encountered this BUG as well a few months ago while coding an app and
spent probably 100 hours coming up with a solution. I even went so far as
coding a test app like greg has done watching it work flawlessly on anything
other than a HT P4. Really not sure how this can be called a matter of
personal taste. Its a bug in winsock plain and simple... just reading this
thread brings back evil memories...
RAID it and fix it.

"Wedson Almeida Filho [MSFT]"
<WedsonAlmeidaFilhoMSFT@discussions.microsoft.com> wrote in message
news:9C04EEC3-7574-45AA-B957-382A728DB6A1@microsoft.com...
> Hi Greg,
>
> > Just because the workaround is in the application code, does not mean
the
> > bug is there. I believe the bug is clearly in MFC. It is receiving a
socket
> > notification mesage, and then it sometimes fails to re-enable
notifications.
>
> The async notification mechanism has roughly two "states": one in which it
> will *not* send notifications and another one where it will send
> notifications. Once it sends a notification it goes into the second state;
> "re-enabling" functions make it go back to the first state. For FD_READ,
the
> re-enabling functions are the recv functions plus WSAAsyncSelect itself.
>
> So, when you get the very first FD_READ, you call a recv function and
> therefore notifications will be reenabled; if there is more data to be
read,
> another notification will be sent. In your case, you're calling receive
again
> before consuming the notification just sent, which is perfectly fine from
a
> Winsock perspective.
>
> When time comes to consume the new FD_READs, from a Winsock perspective,
you
> should be ready to handle WSAEWOULDBLOCK errors because you called more
than
> one recv for a single FD_READ.
>
> The MFC design is different though. When FD_READ notifications are
received,
> they first check if there really is data waiting to be read, if that's the
> case, your function will be called, otherwise it won't. The reason for
this
> is simple: the user doesn't have to deal with WSAEWOULDBLOCK errors as
long
> as he/she doesn't call recv more than once.
>
> Going back to the extra FD_READs: if data is not available anymore
(remember
> you've read more data), your callback functions won't be called again, and
> therefore no re-enabling will occur. Note that it's not MFC that
re-enables
> the notifications, it's you by calling recv or WSAAsyncSelect.
>
> > If MFC doesn't want to handle that case for some reason, then you guys
may
> > as well have Receive return an error immediately if I don't read all the
> > data, right? Because you know its going to lead to failures. And at the
very
> > least, you should put the statement "you should make only one Receive
call
> > per OnReceive function" in very clear terms in the documentation for
> > Receive(). You should certainly not just bury it in a KB article (which
I
> > never saw before, despite many many search attempts to find info while
> > troubleshooting this MFC bug).
>
> You don't have to read all the data in one shot, but you have to call recv
> only once per FD_READ if you want to use MFC, that's by design (as I said
> before, to simplify things so that you don't have to handle WSAEWOULDBLOCK
> errors).
>
> If you want to call recv multiple times for each FD_READ, consider using
> Winsock without MFC.
>
> Thanks,
> --Wedson



Relevant Pages

  • Re: BUG in Winsock on P4 HT CPU
    ... I believe the bug is clearly in MFC. ... and then it sometimes fails to re-enable notifications. ... re-enabling functions are the recv functions plus WSAAsyncSelect itself. ...
    (microsoft.public.win32.programmer.networks)
  • Bug Tracking with Event Based Notifications
    ... Bug Tracking with Event Triggered Email Notifications ... QuickBugs 2.0, a development tool for reporting, tracking and managing ... QuickBugs provides powerful, yet easy to use bug tracking. ... that may include any combination of field values in a bug report. ...
    (comp.object)
  • Re: Font switching on different sizes???
    ... I'm not sure if I have to be happy that I managed to identify a rare MFC ... It is very easy to reproduce the bug... ... also with every font specified... ... and when specifying positive value instead - The bug ...
    (microsoft.public.vc.mfc)
  • CToolBarCtrl::GetButtonInfo Bug?
    ... I'm not sure if this is a bug in my code or a bug in MFC. ... - Add a new toolbar to this app. ... and then call the Toggle method. ...
    (microsoft.public.vc.mfc)
  • Re: MFC 9 issue with CSplitterWndEX
    ... The bug is minor enough that it doesn't justify the expense and risk of publishing a fixed version for MFC 9. ... Everything (except one feature) will work as normal: you won't be able to use the IsKindOf feature to know that CMySplitterWnd is really derived from CSplitterWndEx. ...
    (microsoft.public.vc.mfc)