[fpc-devel] Threads and alot of crap continued

[Vinzent Hoefler]

On Wednesday 08 November 2006 09:27, Ales Katona wrote:
> On st , 2006-11-08 at 07:35 +0000, Vinzent Hoefler wrote:
> > On Tuesday 07 November 2006 16:10, Ales Katona wrote:
> > > As for general use, you can't do a Timer this way.
> >
> > Believe me, I can. :)
> >
> > > You can't just put
> > > a TTimer in which works in it's own thread and then calls some
> > > callback in it's own thread,
> >
> > I even call the callback of another thread. :P
>
> No you can't.

You still refuse to tell me why, so please stop telling me what I can't 
do, especially when I *am* doing it. Of course the procedures in 
question are protected against concurrent execution from different 
threads at the same time. This was needed anyway, because the object 
was designed to be called from different threads anyway. So adding a 
"timed" call from another thread wasn't too hard, as you probably can 
imagine.

Of course I am not using this GUI based TTimer object, I was talking 
about the concept "timer" in a more general way. Call it signal, if you 
like that better.

> > If you'd do that, the timer event callbacks would be queued and
> > then executed in the context of the main thread.
> > The user is only required to call CheckSynchronized from time to
> > time, but because the accuracy of the time of execution of any
> > associated handler is in the hands of the user anyway as long as
> > you stick to a synchronous solution to avoid putting the burden of
> > locking data to the programmer.
> > As long as you don't want to implement real-time behaviour, I don't
> > even see a problem in that. If the user decides to not call/execute
> > any provided "message event loop", the execution of the timer
> > handler code will be deferred until the end of the universe anyway.
>
> This is exactly the "oh-so-complex" solution I use in lNet,

Let me quote yourself: "Apart from asynchronous stuff like watching 
handles etc. I don't see much use for this relativly complicated 
program model."

So you yourself seem to look at it as "complex" somehow.

> and is basicly the only solution.

Well, using a (priority) message queue is a common solution, yes. Yet 
it's not necessarily the only one. :P

It all depends on what you're trying to accomplish. I still like to have 
a "asynchronous timer event" model. It would still simplify some code.


Vinzent.