[fpc-devel] Threads and alot of crap continued

Vinzent Hoefler JeLlyFish.software at gmx.net
Wed Nov 8 14:04:25 CET 2006

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;

      SysUtils.Sleep (self.Interval);
   until self.Terminated;

   // Last Action Hero.
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.


More information about the fpc-devel mailing list