[fpc-devel] Threads and alot of crap continued

[Ales Katona]

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.
> 
> > unless the users are informed, and-or
> > the thing is locked and protected but you can't do that from within a
> > TThread (because you don't know what the callback code is).
> 
> Well, in Turbo Pascal I could write interrupt handlers the wrong way, 
> without locking code/data in question and nobody cared about that 
> simple fact.
> 
> But if that's so complex: Why don't you use the usual synchronization 
> stuff then to put the asynchronous timer event in a message queue using 
> Synchronized?
> 
> > In case of gui TTimer this cannot happen because it's not threaded,
> > so the userloop would first finish, then the user function returns
> > and the main gui loop does it's stuff (this is my oh-so-complicated
> > part, done by the gui).
> 
> The problem in a portable general solution is that the may be no "main 
> gui loop" and you can't just write one and force anyone to use it, 
> right?
> 
> So why don't you use Synchronized/CheckSynchronize (or whatever it's 
> called) then?
> 
> 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, and is
basicly the only solution.
> 
> 
> Vinzent.
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel