[fpc-devel] Threads and alot of crap continued

[Vinzent Hoefler]

On Wednesday 08 November 2006 12:44, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> > So, the semantics would be about the same as in a signal (apart
> > from the "softer" timing), but you would have much less
> > restrictions in the handler's implementation compared to a real OS
> > signal, which acts more like an interrupt.
>
> Impossible.

Yeah, right. So this:

--- 8< ---
{/= tFlusher.Execute =================================================\}
{                                                                      }
{\====================================================================/}
procedure tFlusher.Execute;
begin
   self.Started.SetEvent;

   repeat
      SysUtils.Sleep (self.Interval);
      self.Logger.Flush;
   until self.Terminated;

   // Last Action Hero.
   self.Logger.Flush;
end {tFlusher.Execute};
--- 8< ---

is totally impossible to work? To implement something less crude you 
could either implement a "delay until" by checking the point in time, 
the threads gets woken up or on UNIX you could even sigwait() for 
SIGALARM and (re)set it accordingly.

> You'll end with TThread.Synchronize, but without its
> advantage of knowing in which thread it runs, because the entire
> *point* of a GUI thread is that it's not doing anything for 99% of
> the time (waiting for user input only).

I don't a GUI thread. Currently I have up to 24 threads processing image 
data and writing log information (which I don't want to be written line 
by line, that's why I collect them in a queue for a couple of seconds 
before actually writing it to a file) and some other threads processing 
RPC requests. And only one of them provides an RPC interface to 
something you'd call GUI.

But of course, automatically calling methods by a "timer" with such 
semantics is totally impossible. Guess I have to rethink, why it 
actually works.


Vinzent.