> Is there *any* way to slow down
> ICS, so message queue overflow won't occur so often?

Unless you use UDP or wsoSIO_RCVALL option, there is no reason to have a 
message queue overflow.
Using TCP, if you don't read data as fast as the sender is able to send, the 
protocol is designed so
that sender stop sending (TCP is a "windowed" protocol. Once the "window" is 
full of packets without
ACK, the sender stop sending).

Well I see a possibility: maybe you have a receive buffer too small. Each time 
you read a buffer,
winsock will immediately post a new message if there is more data in his 
internal buffer (4 or 8KB
if I remember well).

Have you tried the conditional  TOMASEK ?
Have you tried the option wsoNoReceiveLoop ?

--
[EMAIL PROTECTED]
Auteur du freeware ICS - Internet Component Suite
Auteur du freeware MidWare - Multi-tiers framework
http://www.overbyte.be


----- Original Message ----- 
From: "Piotr Hellrayzer Dałek" <[EMAIL PROTECTED]>
To: "TWSocket" <twsocket@elists.org>
Sent: Sunday, April 24, 2005 1:25 PM
Subject: [twsocket] Any alternatives to multithreading?


> 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
>


-- 
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