[fpc-devel] daemonapp 100% cpu easting fix

[Bogusław Brandys]

Michael Van Canneyt wrote:
> 
> On Sat, 17 Nov 2007, Mattias Gaertner wrote:
> 
>> On Sat, 17 Nov 2007 10:12:30 -0200
>> Steve Howe <howesteve at gmail.com> wrote:
>>
>>> Hello all,
>>>
>>> While using the daemonapp.pp unit to code a daemon, I've found that 
>>> applications that it eat 100% of the CPU. After tracking and
>>> debugging, I've found out that the problem is in the daemonapp's
>>> TDaemonThread.Execute() method:
>>>
>>> procedure TDaemonThread.Execute;
>>>
>>> begin
>>>   If FDaemon.Start then
>>>     begin
>>>     FDaemon.Status:=csRunning;
>>>     StartServiceExecute;
>>>     if not FDaemon.Execute then
>>>       begin
>>>       While Not Terminated do
>>>         CheckControlMessage(True);
>>>       CheckControlMessage(False);
>>>       end;
>>>     end;
>>> end;
>>>
>>> The loop has no interval so it just consumes all free CPU. 
>> Then CheckControlMessage has a bug. The 'True' means it should wait for
>> the next message.
>> But I see no 'virtual' and no code in this function - strange (fpc
>> 2.3.1).
> 
> You are right, I committed the 'fix' as initially proposed, but moved it to
> the unix version of the CheckControlMessage; 
> 
> Checking for this message is not yet implemented on unix. The idea is to open a
> 'control' socket using simpleIPC and to check on this socket for a message.
> 
> Michael.
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
> 


Long time ago I had the same problem with delphi based NT service code 
which was using loop in ServiceMain procedure.Then I used such code :

  WaitForSingleObject(EndEvent,INFINITE);
  CloseHandle(EndEvent);


then in a control procedure SetEvent(EndEvent) was used
to signal end of execution (SERVICE_CONTROL_STOP and 
SERVICE_CONTROL_SHUTDOWN options)

This trick is of course Windows only but it let me drop CPU usage from 
very high all the time to almost zero when working thread is not doing 
any CPU intensive task.


Boguslaw