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.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
