On Friday 22 June 2007 07:28, Michael Van Canneyt wrote:
- Don't use synchronize to fire the timer, because that limits
the use of timers to the main thread.
This one is harder, and I must confess I don't have a clue
on how to implement this in a platform independent manner...
Well, independently from Graeme I implemented something like that
already, closely resembling the Ada2005 Ada.Real_Time.Timing_Events
package. Implemented targets would be Win32 and Unix (tested for Linux,
but as I am only using POSIX-functionality it should run on any other
Unix, too).
Problems are:
1) All fired events are currently executed in a single thread, meaning,
the can quite easily block out each other. Could be easily changed,
although starting thousand of threads may turn out to be a bad idea. ;)
Currently I am thinking about getting away from a global scheduler and
setting up several ones, this would cut down the number of threads in
case of many timing events being active and could be used to implement
a sort of user defined priorization (fast executing/important vs. slow
executing/less important events).
2) Event execution is always independent (outside) of the main thread,
so a user must take care of all the multi-threading hassles.
3) With the current implementation you can't use Destroy on such a
Timing_Event, because those objects are used in another thread, so
instead of calling Destroy you'd have to used Finalize to mark such
an event as done. It will be freed later from the scheduling loop.
4) On Unix it uses a signal to wake up the thread on changes in the
timing event queue, so someone must ensure that this signal is blocked
in all other threads and may not be used otherwise.
6) It uses some more modules (especially some Calendar unit which uses
integers for duration types to avoid drifting issues you'd have if
you'd used the floating point TDateTime).
7) As I am currently rewriting the stuff for the priority queue I am
going to be using, I won't post any sourcecode yet, apart from the
interface:
-- 8 --
//-- @abstract(Provides a (crude) scheduling object to install handlers
//-- to be executed at some future point in time.)
//-- It closely resembles the @code(Ada2005 Ada.Real_Time.Timing_Events)
//-- package, so for the correct semantics of the operations (which are
//-- currently not 100% guaranteed in this implementation) you may also
//-- refer to the Ada2005 language reference manual.
unit
Timing_Events;
interface
uses
Calendar,
SyncObjs;
type
Timing_Event = class; // Forward declaration for criss-cross type
// dependency.
type
//-- @abstract(Type for the event handler @italic(callback).)
Timing_Event_Handler =
procedure (const Event : Timing_Event) of object;
type
//-- @abstract(The base type indicating a timing event.)
//-- It stores the next scheduled execution and the handler to be
//-- executed.
Timing_Event = class (tObject)
public
{/= Create =\}
{}
{\==/}
//-- @abstract(The usual constructor. Initializes all the needed
//-- internals.)
constructor Create;
{/= Destroy \}
{}
{\==/}
//-- @abstract(Cleans up object internals.)
//-- Due to its inherent asynchronous usage, DO NOT call @code(
//-- Free) or even @code(Destroy) directly. Leave the freeing up
//-- to the @link(Finalize) subroutine.)
destructor Destroy; override;
{/= Finalize ===\}
{}
{\==/}
//-- @abstract(Marks the object for finalization.)
//-- This is a replacement for @code(Free) which can not be used
//-- in this asynchronous context. Instead if you call @code(
//-- Finalize) the event will be marked for deletion and @code(
//-- Free) will then be called on the next run of the scheduler.
//-- Basically this just means that the freeing will be deferred
//-- an indefinite time. In case the event in currently scheduled
//-- to run in a moment, this subroutine will not return until the
//-- run is over.
//--
//-- @bold(Do NOT) call any methods of the instance after having
//-- called @code(Finalize)!
procedure Finalize; virtual;
{/= Set_Handler \}
{}
