Hi! Okay, this is discussed few times a year, and probably FAQ got something about, but..
The problem is simple. I didn't realized that when user has slow CPU and fast LAN[1], my HCM can't handle that well - looks like hung, and downloads slower than it's possible. I won't overcome the downloading speed problem, but I have to do something with that semi-hanging (occuring due to message queue overflow). I know that ICS itself isn't such bottleneck here, probably I could get it working better with that message-parsing code put into a separate thread. But then, I'd had to start playing with sync-mechanisms, mutexes, semaphores, and so on, and I don't want to (I already did, and noticed ENORMOUS slowdown; maybe I did something wrong, but I was sure that performance degradation had to occur). Is there *any* way to slow down ICS, so message queue overflow won't occur so often? The only solution I've found so far, that doesn't require whole application recoding, is putting ICS connections into separate thread, and post some messages to the main form message queue (so message parsing will still occur in separate thread, but saving to a base file and adding to index file and (if needed) index tables in memory - in main thread. This would suppress any need for critical sections or something like that, and perhaps I still won't have any race conditions). [1] P60 and 100BaseT ethernet; or even [EMAIL PROTECTED] -- Piotr "Hellrayzer" Dalek Author of ICS-Based Hellcore Mailer - an Outlook Express killer http://www.hcm.prv.pl [EMAIL PROTECTED] ---------------------------------------------------------------------- PS. Zdjecia samochodow, bardzo duzo, bardzo fajne galerie... >>> http://link.interia.pl/f1877 -- To unsubscribe or change your settings for TWSocket mailing list please goto http://www.elists.org/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be