Are you trying to tell me M$ Windows has bugs in it ?!!
David Gravereaux
meeting. I still quote that unnamed person every now and then just for kicks :)
[Dave Welton, *you know who* I'm talking about :)]
Years ago at a programming job, I was tasked to find out why the tclhttpd server
would stop responding to incoming requests when under extremely heavy load. It
turned-out to be winsock itself losing internal data every now and then with the
WSAAsyncSelect method of notification until some internal queue became empty and
all accepts would halt. It wasn't Tcl's fault!
So I'm having a meeting with the "lead developer", or I should say the guy who
thought he was, and showed him the logs with highlighted points where ports were
getting dropped, and he screams out that now infamous quote to me :)
Anyways, thought I'd share the story as it kills me every time I think about it.
That company's owner supported me authoring and publicly releasing IOCPSOCK, a
replacement winsock channel driver as an extension for the WinNT OS flavors. It
uses overlapped-I/O with the completion port notification method. You can pick it
up @ http://sf.net/projects/iocpsock if you want.
Here's a little comparison chart of winsock I/O methods, FYI:
http://www.microsoft.com/mspress/books/sampchap/5726a.aspx#132
Me: "Well, actually there are better ways to manage sockets as I have listed here
and would like to try.."
Him: "Get out! This is BS. You're full of it! Microsoft would not release their
OS with bugs like this!!"
;)
--
I think nighttime is dark so you can imagine your fears with less
distraction. -- Calvin
Christopher Nelson
> ...
> Me: "Well, actually there are better ways to manage sockets as I have
> listed here and would like to try.."
>
> Him: "Get out! This is BS. You're full of it! Microsoft would not
> release theirOS with bugs like this!!"
Reminds me of the Three Rules of Debugging (prominently posted in my
office):
1) The problem is *not* in the system hardware.
2) The problem is *not* in the system software.
3) *Everything* is suspect, *including* Rules 1 and 2.
Of course, these days, I'm working on embedded Linux on prototype
hardware so fairly often the problem is in the system hardware or
software but still...
Uwe Klein
> Reminds me of the Three Rules of Debugging (prominently posted in my
> office):
0) The problem is situated between a mirrorsymmetric set of ears.
>
> 1) The problem is *not* in the system hardware.
>
> 2) The problem is *not* in the system software.
>
> 3) *Everything* is suspect, *including* Rules 1 and 2.
>
> Of course, these days, I'm working on embedded Linux on prototype
> hardware so fairly often the problem is in the system hardware or
> software but still...
>
uwe