Re: [fpc-pascal] Daemon using TTimer on Windows
On Tue, Jul 3, 2018 at 11:36 AM, Giuliano Colla wrote: > Il 03/07/2018 15:14, Marcos Douglas B. Santos ha scritto: > >> Can we sleep a thread for minutes or even hours without any problems? >> The OS will not kill the thread? > > On Linux environment, sample situation on one of our servers: > >> ├─hald───hald-runner─┬─hald-addon-acpi │ ├─hald-addon-keyb │ >> └─2*[hald-addon-stor] 16:27:34 up 567 days, 20:40, 1 user, load average: >> 0.02, 0.01, 0.00 > > > Hald threads are unused since 567 days (they're triggered by the insertion > of new hardware, which never happened on our server) and are still there! > > On Windows a CTRL-ALT-DEL will show you a lot of useless threads activated > at power on, and sleeping since then. > > OS may decide to swap them off, so that activation may be slower, but never > to kill them. Very interesting! Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Daemon using TTimer on Windows
Il 03/07/2018 15:14, Marcos Douglas B. Santos ha scritto: Can we sleep a thread for minutes or even hours without any problems? The OS will not kill the thread? On Linux environment, sample situation on one of our servers: ├─hald───hald-runner─┬─hald-addon-acpi │ ├─hald-addon-keyb │ └─2*[hald-addon-stor] 16:27:34 up 567 days, 20:40, 1 user, load average: 0.02, 0.01, 0.00 Hald threads are unused since 567 days (they're triggered by the insertion of new hardware, which never happened on our server) and are still there! On Windows a CTRL-ALT-DEL will show you a lot of useless threads activated at power on, and sleeping since then. OS may decide to swap them off, so that activation may be slower, but never to kill them. Giuliano ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Daemon using TTimer on Windows
On Tue, 2018-07-03 at 10:14 -0300, Marcos Douglas B. Santos wrote: > > Can we sleep a thread for minutes or even hours without any problems? > The OS will not kill the thread? > Sorry, I simply don't know. Try it. -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Daemon using TTimer on Windows
On Mon, Jul 2, 2018 at 6:28 PM, Marc Santhoff wrote: > On Sat, 2018-06-30 at 17:57 -0300, Marcos Douglas B. Santos wrote: >> >> My question is: Nowadays, can I use TTimer with no restrictions in a >> daemon application on Windows? If not, which could be a possible >> solution? >> > > Some years ago Graeme G. posted a solution to that problem. It's attached to > this mail, hoping hte list accepts pure text attachemnts, although I hoped it > would have been integrated in fpc/lazarus. I've received the file, thank you. Can we sleep a thread for minutes or even hours without any problems? The OS will not kill the thread? Regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Daemon using TTimer on Windows
On Sat, 2018-06-30 at 17:57 -0300, Marcos Douglas B. Santos wrote:
>
> My question is: Nowadays, can I use TTimer with no restrictions in a
> daemon application on Windows? If not, which could be a possible
> solution?
>
Some years ago Graeme G. posted a solution to that problem. It's attached to
this mail, hoping hte list accepts pure text attachemnts, although I hoped it
would have been integrated in fpc/lazarus.
HTH,
Marc
--
Marc Santhoff {
A basic thread based timer component. Can be used in GUI and non-GUI apps.
Author: Graeme Geldenhuys
}
unit ThreadTimer;
{$mode objfpc}{$H+}
interface
uses
Classes;
type
TFPTimer = class; // forward declaration
TFPTimerThread = class(TThread)
private
FTimer: TFPTimer;
protected
procedure DoExecute;
procedure Execute; override;
public
constructor CreateTimerThread(Timer: TFPTimer);
end;
TFPTimer = class(TComponent)
private
FInterval: Integer;
FPriority: TThreadPriority;
FOnTimer: TNotifyEvent;
FContinue: Boolean;
FRunning: Boolean;
FEnabled: Boolean;
procedure SetEnabled(Value: Boolean );
protected
procedure StartTimer;
procedure StopTimer;
propertyContinue: Boolean read FContinue write FContinue;
public
constructor Create(AOwner: TComponent); override;
procedure On;
procedure Off;
published
propertyEnabled: Boolean read FEnabled write SetEnabled;
propertyInterval: Integer read FInterval write FInterval;
propertyThreadPriority: TThreadPriority read FPriority write FPriority default tpNormal;
propertyOnTimer: TNotifyEvent read FOnTimer write FOnTimer;
end;
implementation
uses
SysUtils;
{ No need to pull in the Windows unit. Also this works on all platforms. }
function _GetTickCount: Cardinal;
begin
Result := Cardinal(Trunc(Now * 24 * 60 * 60 * 1000));
end;
{ TFPTimerThread }
constructor TFPTimerThread.CreateTimerThread(Timer: TFPTimer);
begin
inherited Create(True);
FTimer := Timer;
FreeOnTerminate := True;
end;
procedure TFPTimerThread.Execute;
var
SleepTime: Integer;
Last: Cardinal;
begin
while FTimer.Continue do
begin
Last := _GetTickCount;
Synchronize(@DoExecute);
SleepTime := FTimer.FInterval - (_GetTickCount - Last);
if SleepTime < 10 then
SleepTime := 10;
Sleep(SleepTime);
end;
end;
procedure TFPTimerThread.DoExecute;
begin
if Assigned(FTimer.OnTimer) then FTimer.OnTimer(FTimer);
end;
{ TFPTimer }
constructor TFPTimer.Create(AOwner: TComponent);
begin
inherited;
FPriority := tpNormal;
end;
procedure TFPTimer.SetEnabled(Value: Boolean);
begin
if Value <> FEnabled then
begin
FEnabled := Value;
if FEnabled then
StartTimer
else
StopTimer;
end;
end;
procedure TFPTimer.StartTimer;
begin
if FRunning then
Exit; //==>
FContinue := True;
if not (csDesigning in ComponentState) then
begin
with TFPTimerThread.CreateTimerThread(Self) do
begin
Priority := FPriority;
Resume;
end;
end;
FRunning := True;
end;
procedure TFPTimer.StopTimer;
begin
FContinue := False;
FRunning := False;
end;
procedure TFPTimer.On;
begin
StartTimer;
end;
procedure TFPTimer.Off;
begin
StopTimer;
end;
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Daemon using TTimer on Windows
On Sun, Jul 1, 2018 at 8:06 AM, Marcos Douglas B. Santos wrote: > On Sat, Jun 30, 2018 at 9:13 PM, R0b0t1 wrote: >> Anyway - does TTimer use the WM_TIMER message? That is the type tied >> to the GUI. Even if you need to use WM_TIMER for some reason you can, >> as services should be run in "session 0" and should have access to a >> GUI. The latter is, I think, a compatibility option you can enable. > > I didn't understand this "session 0"... is it a something related to > Lazarus or Windows? > It is something related to Windows, and the reason services can not use the GUI. A session is started for each terminal services instance. A session contains multiple window stations, each of which contains at least one desktop, one of which accepts keyboard/mouse input. One terminal services instance exists by default, and it is the "local session," i.e. the one that consumes physical keyboard and mouse input and outputs to the screen. It used to be that this local session was the one that ran services in addition to logged in user programs. This made it easier than it should have been to exploit service processes, so they made session 0 noninteractive and now the console logs in to session 1. One exploit was particularly bad. You can forcibly register WM_TIMER callbacks for an application and have that callback run in that processes' thread. As long as services were running in the same desktop you could trivially run code as SYSTEM. More information at https://blogs.technet.microsoft.com/askperf/2007/04/27/application-compatibility-session-0-isolation/ but it is not a lot. There is a better MSDN article I could not find. Cheers, R0b0t1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Daemon using TTimer on Windows
On Sun, Jul 1, 2018 at 2:15 AM, Martin Schreiber wrote: > On Saturday 30 June 2018 22:57:47 Marcos Douglas B. Santos wrote: > >>If not, which could be a possible >> solution? >> > You could use a MSEgui application, instead of > " > uses > msegui; > " > write > " > uses > msenogui; > " > in "program" source file. It will have an event queue and the usual event > driven programming paradigm including the use of datamodules and graphically > placed non visual components. Examples are here: > > https://gitlab.com/mseide-msegui/mseuniverse/tree/master/attic/msedocumenting/mse/trunk/help/tutorials/nogui Hey Martin, thanks to give me another good option. I'll check it. Regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Daemon using TTimer on Windows
On Sat, Jun 30, 2018 at 9:13 PM, R0b0t1 wrote: > On Sat, Jun 30, 2018 at 3:57 PM, Marcos Douglas B. Santos > wrote: >> Hi, >> >> I need to build a daemon app on Windows. It will need a timer to >> performe some tasks. This timer could be big among 15 min, 30 min, 2 >> hours, etc. >> >> I thought that I can use TTimer but I've always heard that it's not >> possible because some problems related with "NoGUI" stuff. >> >> I've found a thread[1] which talks about that but they haven't >> provided a real solution, at least for Windows. >> >> My question is: Nowadays, can I use TTimer with no restrictions in a >> daemon application on Windows? If not, which could be a possible >> solution? >> > > If all your service does is wait for the timer you should instead use > a scheduled task. Actually, it could be a better idea. I will check the requirements and think if this would be possible. > Anyway - does TTimer use the WM_TIMER message? That is the type tied > to the GUI. Even if you need to use WM_TIMER for some reason you can, > as services should be run in "session 0" and should have access to a > GUI. The latter is, I think, a compatibility option you can enable. I didn't understand this "session 0"... is it a something related to Lazarus or Windows? > If you are not opposed to OS-level primitives you should use waitable > timers > (https://docs.microsoft.com/en-us/windows/desktop/sync/using-waitable-timer-objects). > Using waitable timers you can also wake the computer from sleep. I'm not opposed at all. Indeed I didn't know these functions... sounds a good option. Thanks. Regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Daemon using TTimer on Windows
On Saturday 30 June 2018 22:57:47 Marcos Douglas B. Santos wrote: >If not, which could be a possible > solution? > You could use a MSEgui application, instead of " uses msegui; " write " uses msenogui; " in "program" source file. It will have an event queue and the usual event driven programming paradigm including the use of datamodules and graphically placed non visual components. Examples are here: https://gitlab.com/mseide-msegui/mseuniverse/tree/master/attic/msedocumenting/mse/trunk/help/tutorials/nogui Martin ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Daemon using TTimer on Windows
On Sat, Jun 30, 2018 at 3:57 PM, Marcos Douglas B. Santos wrote: > Hi, > > I need to build a daemon app on Windows. It will need a timer to > performe some tasks. This timer could be big among 15 min, 30 min, 2 > hours, etc. > > I thought that I can use TTimer but I've always heard that it's not > possible because some problems related with "NoGUI" stuff. > > I've found a thread[1] which talks about that but they haven't > provided a real solution, at least for Windows. > > My question is: Nowadays, can I use TTimer with no restrictions in a > daemon application on Windows? If not, which could be a possible > solution? > If all your service does is wait for the timer you should instead use a scheduled task. Anyway - does TTimer use the WM_TIMER message? That is the type tied to the GUI. Even if you need to use WM_TIMER for some reason you can, as services should be run in "session 0" and should have access to a GUI. The latter is, I think, a compatibility option you can enable. If you are not opposed to OS-level primitives you should use waitable timers (https://docs.microsoft.com/en-us/windows/desktop/sync/using-waitable-timer-objects). Using waitable timers you can also wake the computer from sleep. Cheers, R0b0t1 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
