[fpc-devel] Threads and alot of crap continued

[Michael Schnell]

>  
> If you need an event-based loop and callbacks you can make 
> TApplication. If you don't want LCL ok, then make your own, it's 
> generaly needed to be very problem-specific anyhow, eg: the TLEventers 
> I use are ment for handling events on handles (files and sockets atm, 
> sockets only in windows).
TApplication supposedly is platform specific, as e.g. Delphi or LCL use 
OS mechanism for GUI events and there is no platform independent message 
implementation in FPC. I don't see why it should be "problem-specific". 
A mechanism that waits for a message and creates an event from same 
should be quite universal.

>  
> If you want a "Timer" a "polling" mechanism has to take place which 
> looks if something happened on some timer for example, OnTimer is 
> "ready to be fired" (you can't call callbacks in threads, and if you 
> go single-threaded you have to provide the main loop hooks).
I don't think so. To do a TTimer implementation that does not use GUI 
events, I would e.g. use a thread that sleeps periodically wakes up and 
sends a message to the main thread. Here the TApplication event 
scheduler would fire an Event in the main thread when appropriate (at 
once if idle, when coming back from the previous event or when 
"ProcessMessages is called).

>  
> So basicly, let's say TTimer is in RTL and there's some event 
> mechanism already too, you'd have to do something like this:
>  
> procedure init;
> begin
>   Timer.Timeout:=somenumber;
>   Timer.OnTimer:=@somecallback;
>   EventHandler.RegisterTimer(Timer); // could be the other way around
> end;
>  
> procedure MainLoop;
> begin
>   EventHandler.HandleEvents; // if eventhandler after polling all 
> timers in it's watchlist find out some has it's interval done, it 
> fires it's callback
> end;
>  
> begin
>   Init;
>   MainLoop;
> end.
Using an OS-Timer would save a thread for each timer. Here The Event 
Scheduler would need to be aware not only of messages but of timers as 
well. Maybe this is a better way to do it.

>  
>  
> Apart from asynchronous stuff like watching handles etc. I don't see 
> much use for this relativly complicated program model. Remember you 
> need to call the "HandleEvents" as fast as possible to stay effective 
> (otherwise you lose precision)

It's necessary to be compatible with Delphi paradigms. Here I will need 
to port "embedded" programs done in Delphi by my colleagues to GUI-less 
ARM-Linux. Of course this is just _my_ motivation, but IMHO prototyping 
embedded applications in Delphi (or Lazarus) and porting them to run on 
a smaller/cheaper platform than a Windows PC is a great way to do things 
like communication servers.

-Michael