RE: [msvc] IOCP

[Ehsan Akhgari]

Right I've fix the first problem.  What I was doing is in the callback I had freed some memory (dropping a connection) but did not check the pointer which I had then used later on to try and read data off the network.  This didn't crash ( never does when you want it to )  but it did create a first chance exception.  The problem, really showed itself when I tried to allocate more memory - the debugger showed that the listening thread memory allocation was going wrong. First, a clarification of first chance notifications (BTW, calling them first chance 'exceptions' doesn't seem quite right to me, because of the reason I will mention):   Every exception under MSVC (C++ exceptions, and Win32 Structured Exceptions) is raised using the Kernel32 function RaiseException.  This function checks to see if a debugger is present (IsDebuggerPresent( )).  If one's present, it informs the debugger before raising the exception.  The debugger then can notify you, and this is called a first chance notification.  Usually, at this stage, debuggers ask you whether you want to pass the exception to the debugee.  If you say no, then the debugee program will not be able to catch the exception.  After this, RaiseException goes on to actually raise (throw) the exception by searching in the list of exception handlers registered for the current thread.  If no handler capable of handling the exception is found, the program will be terminated by the OS, or you will get a second chance notification if the program is being debugged.  Now, if an exception is thrown and handled gracefully, then you won't get any second chance notification, and because the debugger is by default set not to notify first chance notifications, you won't notice anything.  If no handler is found, the second chance notification is raised, and you'll know that you're having something we know as an unhandled exception.  If you configure the debugger to notify you on first chance notifications, then you will be notified every time RaiseException is called.  Generally, in that case, if you don't get a second chance exception, your app has not actually crashed.  That means that an exception had been thrown and handled gracefully.  There are functions which actually rely on throwing an exception and catching it for correct functioning - for those, this first chance notification is safe.  However, other functions might encounter exceptions because you're doing something wrong (e.g. pass them a wrong parameter) albeit they handle it gracefully; for those functions, a first chance exception is a sign of something fishy going on.   So, the short story is that first chance notifications are not a sign of hazard by themselves. I'm getting a first chance exception while getting the time.  Each connection object has a has a function to get the time so I can see when the last read/write operation tool place and then decide whether to drop the connection later on or not.  Now under certain conditions the server should drop the connection such as someone logging on with the wrong ID.    To do this the server send a Error code to the user and then disconnects - closing the socket, freeing memory etc.  However the Callback gets called again but the Parameters hold information that's not valid. I'm not sure if I understand what you mean here. --------- Ehsan Akhgari www.farda-tech.com List Owner: [EMAIL PROTECTED] [Email: [EMAIL PROTECTED]] [WWW: http://www.beginthread.com/Ehsan ] And when I saw my devil, I found him serious, thorough, profound, solemn: he was the spirit of gravity- through him all things fall. -Thus Spoke Zarathustra, F. W. Nietzsche