Olivier Sannier wrote:

> 
>         if bMore then
>             Sleep(1); { to avoid 100% CPU }
> 
> At line 4231, right after the end of the try except block.
> To me this has little to no effect as the sleep is only done when
> bMore is True.
> What do you think of this proposal?

That would slow down performance when you use the component as designed.
When the application is idle it should read incomming data immediately.
There is no reason to wait until a certain amount of data is pending
to be read from winsock. 

--
Arno Garrels [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html


Olivier Sannier wrote:
> Hi,
> 
> I'm using TWSocketS with a custom TWSocket derived class called
> TMyClientSocket to implement a TCP/IP server.
> I have overridden TriggerDataAvailable in TMyClientSocket in such a
> way: 
> 
> function TROAsyncSuperTcpServerSocketClient.TriggerDataAvailable(
>   Error: Word): Boolean;
> begin
>   inherited TriggerDataAvailable(Error);
> 
>   NotifyDataAvailable;
> 
>   // Return True to indicate that we do not want the data to be
> dropped.   Result := True;
> end;
> 
> 
> The NotifyDataAvailable sets a flag in an object associated to the
> client socket that will then read the available bytes. But it will not
> do so immediately, clearly after the TriggerDataAvailable has
> returned. This does not prove to be a problem because all data is
> queued up until it is actually read, up to a certain limit that I
> doubt I'll ever reach. Usually, this takes a few milliseconds but it
> happens sometimes that it takes up to 10 seconds. Ok, this is
> relatively rare for production use, but because I'm doing tests on
> the server, I'm seeing this quite often. And this is where I have a
> problem, because while the data is waiting to be read, the processor
> usage is 100% (or 1CPU on multi cpu systems). I traced it and that's
> because TCustomWSocket.ASyncReceive does a loop while the bMore
> variable is True, without ever giving the operating system to do
> anything. Hence the 100%CPU usage. To me, this could be avoided by
> adding the following two lines at the end of the loop: 
> 
>         if bMore then
>             Sleep(1); { to avoid 100% CPU }
> 
> At line 4231, right after the end of the try except block.
> To me this has little to no effect as the sleep is only done when
> bMore is True.
> What do you think of this proposal?
> 
> Any comments are welcome.
> Regards
> Olivier Sannier
-- 
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