Leaderboard

You say you need it to wake up at fixed intervals. That is exactly what Sleep(..) is for. Keep in mind that 10 milliseconds is a very, very short interval. If we are talking about Windows, then accuracy that low is not guaranteed. As far as I know, it has been improved in recent Windows versions, but generally, you cannot rely on the thread waking up again in exactly 10 milliseconds If you want the thread to wait for something else, you use an Event. You can have the thread wait for an event which is triggered from (for example) your main thread. See System.SyncObjs.pas for event classes.

If you know absolutely nothing about threads, then Sleep can be a first step towards solution. It will at least give you a simple proof of concept code. If you need to learn everything at once it can be overwhelming. But, again, at this point we are discussing the Sleep vs events while we don't even know if we are going in the right direction.

There are many better alternatives to Sleep. https://learn.microsoft.com/en-us/windows/win32/sync/wait-functions#multiple-object-wait-functions The downside of a single Sleep is that it blocks termination of the thread. The downside of multiple Sleep + time checks to allow termination, consumes more CPU. Signals, WaitForXXXX & Timeouts give you all the tools you need to have low cost and responsive threads - even if it requires a little more scaffolding code.

If you want the timer to run in the thread then the thread will not idle. You need to run your timer related code within the Execute method. To simplify, the Execute method is the one that runs in the background thread, thread constructor does not run in the background thread. You have some deep misconceptions about how threads work, but I cannot help you if you don't show your code. Right now you are doing everything wrong and you are not running any code in the background thread.

That means you are creating the TTimer in the main thread to begin with, not in the background thread. That's exactly how TTimer already works. Its constructor creates a hidden window in the calling thread, which when activated will then receive timer messages from that same thread. So the thread that creates the TTimer must have a message loop to receive and dispatch those timer messages. So, you might think about moving the creation of the TTimer into the background thread's Execute() method, and that may work 99% of the time, but know that the creation of that hidden window is not done in a thread-safe manner, so you really should not be using TTimer in a background thread at all. If you really need a thread-based timer, you could just use the Win32 timeSetEvent() function, which is a multimedia timer that runs its callback in a background thread that the OS manages, If you really want to use a custom TThread class, then using TEvent is the simplest option that allows you to terminate the thread on demand, eg: uses ..., Classes, SyncObjs; type TTimerThread = class (TThread) private fEvent: TEvent; fInterval: LongWord; fOnElapsed: TNotifyEvent; protected procedure Execute; override; procedure TerminatedSet; override; public constructor Create(AInterval: LongWord; AOnElapsed: TNotifyEvent); reintroduce; destructor Destroy; end; constructor TTimerThread.Create(AInterval: LongWord; AOnTimer: TNotifyEvent); begin inherited Create(False); fInterval := AInterval; fOnElapsed := AOnElapsed; fEvent := TEvent.Create; end; destructor TTimerThread.Destroy; begin fEvent.Free; inherited Destroy; end; procedure TTimerThread.TerminatedSet; begin fEvent.SetEvent; end; procedure TTimerThread.Execute; begin while fEvent.WaitFor(fInterval) = wrTimeout do fOnElapsed(Self); end;

I disagree. Sleep is only appropriate if the interval is very small and even then I wouldn't use it. The problem is thread termination; If you are using Sleep then the thread cannot be terminated while Sleep is executing. IMO the better solution, as have already been suggested, is to wait on an event with a timeout: If the event times out, do the task. If the event is signaled, terminate the thread. To terminate the thread, signal the event. While waiting on an event is much more complicated than just calling sleep, if one is to use threads one might as well learn how to do these things. Threads are difficult and pretending they aren't will just lead to lessons learned, the hard way, later on.

You cannot terminate the thread while it's blocked by sleep. +1 for SimpleEvent and Waitfor.

You definitely have a misconception about how threads and timers work. Read the other answers and some documentation on the topic.

Into the Execute you need to have a code that will not exit till you need that thread alive. procedure TMyThread.Execute; var LHowMuchToWait: Integer; LDoExit: Boolean; begin try repeat ExecuteMyClass(LHowMuchToWait, LDoExit); Sleep(LHowMuchToWait); until LDoExit or Terminated; finally Terminate; end; end;

The code within Execute method is what runs in the background thread. If you don't have any code there then you don't have a thread. If you want to run a timer in background thread, then you need to create that time in the Execute method , run a loop which handles messages and then release the times when thread terminates. There is plenty of code that needs to go in the Execute method. Background thread that is created by TThread class (at some point) will terminate when it exits the Execute method. Because there is nothing in the Execute method thread will terminate immediately when it runs. (since there is nothing there, it will On the other hand, your thread object instance will be alive until you free it. I cannot tell you more because you haven't shown any code you already have.

https://ib-aid.com/en/articles/detailed-new-features-of-firebird-5-part-1-improvements-in-optimizer My preliminary tests on our product(s) show that FB5 is clearly faster than FB4. Did not need to measure result, because you could see/feel it very easily. When you saw Vista Wheel with FB4, on top of FB5 you can't even see it, form just opens faster. For sure there will be some corner cases when some query, very carefully optimized for older version of FB will perform worse in FB5. At least always there had been some "regressions". But for every new Firebird release, there has been performance increase. FB5 is close to the release, so please evaluate is best as you can, and report any bugs or regressions ASAP, so they could be addressed before release. -Tee-

Look at and compare the call stacks between the multiple hits of the breakpoint.

https://firebirdsql.org/en/firebird-5-0/ New In Firebird 5.0 Summary of New Features Firebird 5.0 introduces many improvements without any changes in architecture or operation, the most important are: Parallel (multi-threaded) operation for backup/restore, sweep and index creation; Partial indices; SKIP LOCKED clause for SELECT WITH LOCK, UPDATE and DELETE statements; Inline minor ODS upgrade; Compiled statement cache; PSQL and SQL profiler; Support for WHEN NOT MATCHED BY SOURCE for MERGE statement; Support multiple rows for DML RETURNING; New built-in functions and packages; Denser record-level compression; Network support for scrollable cursors;