Re: [twsocket] Any alternatives to multithreading?
Hello! >> so message queue overflow won't occur so often? > What exacly flows over ? I mean, on what do you see this ? Application gets unresponsive. Simply refuses to react for mouse clicks, keypresses, anything except network operations. On my home P120 it shows up, when I download many 1-5kB messages with more than 75-100kB/s (actually I get no more than that). There's no problem with large (>1MB) messages, while they're downloaded, everything works fine and transfer speed is also high (>200kB/s). I know that parsing causes these trouble, but I just had to ask for any other solutions than putting network connections and parsers into a separate thread. -- Piotr "Hellrayzer" Dalek Author of ICS-Based Hellcore Mailer - an Outlook Express killer http://www.hcm.prv.pl [EMAIL PROTECTED] -- Startuj z INTERIA.PL! >>> http://link.interia.pl/f186c -- 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
Re: [twsocket] Any alternatives to multithreading?
Hello Piotr, > Is there *any* way to slow down ICS, trottle receiving in a lot of way. Eather by calling the pauze/resume methods, or very simple: Set wsoNoReceiveLoop and _dont_ receive in OnDataAvailable, but set a flag you have data. A while later when your trottling mechanism decide to receive again just call receive of the right socket. then the mechanism start again. > so message queue overflow won't occur so often? What exacly flows over ? I mean, on what do you see this ? --- Rgds, Wilfried http://www.mestdagh.biz -- 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
Re: [twsocket] Any alternatives to multithreading?
Hello! >> 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, > insock 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 ? Just checked it out - no difference... except for TNntpCli which started to give me "10035 Operation Would Block" errors. > Have you tried the option wsoNoReceiveLoop ? Yes, and it didn't helped much. This looks like two (or more) message pumps working "simultaneously", and the ICS pumps have higher priority than application global pump. W... Seems like two-threaded solution is the only solution for my problem :( -- 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
Re: [twsocket] Any alternatives to multithreading?
Piotr Hellrayzer Da³ek wrote: > 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). How does your 'message queue overflow' show up? I had some kind of freezing with enabled life AV-protection, solved it by using an buffered filestream for attachments, and I use a home-grown throttle which calls MsgWaitForMultipleObject very rarely, just often enough to fake taskmanager ;-) > 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, That's what I do in my SmtpCli-apps always. Communication beetween the two threads by Windows-messages, from my expierences it's very fast, due to missing synchronization. > 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] Well, my oldest system is a bit jounger, otherwise I would take a trial to replicate to prob. here. Arno Garrels > > -- > 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
Re: [twsocket] Any alternatives to multithreading?
> 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" 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
[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
