> To minimize the disturbance to the threads, what I do in my logging > routine is this:
Writing to a file is certainly not a minimal disturbance. It's a lengthy process and sure to slow your app down. Back to the IOCP bandwagon. I wrote a nifty logging class where you use sprintf( ) style calls and the log class places your log entry into an IOCP queue. The logging IOCP threads run at a lower priority and only pull stuff off the queue if the system is sufficiently slow enough. Thus the actual disk write doesn't hold up any "production" threads. > This makes the Log() function as quick as possible so the threads are > disturbed as little as possible. Unfortunately, the file doesn't get > written out if the program crashes. Does any one have a suggestion for > getting the file written if there the program crashes without causing > more time to be spent in the Log() function? Yes, the way I mentioned. Then in each of your worker bee threads that have the potential to crash you wrap the whole thing with one big try/catch. If your catch is triggered you can log it and also shut that thread down safely without bringing down the rest of the system. The log will indicated what that thread had been doing before it crashed and then that it actually crashed making it real easy to figure out what was going on. > But that is just a guess. We're not even sure it is caused by high data > rates. Upping the data rate caused the crash on one computer in the > field, but upping the data rate on any of the computers in the office > didn't cause a problem. Run it on slower and slower machines there in your office. /dev
