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;
  inherited TriggerDataAvailable(Error);

  // Return True to indicate that we do not want the data to be dropped.
  Result := True;

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