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

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

Reply via email to