Re: [fpc-devel] Threads and alot of crap continued

[Michael Schnell]

Vinzent Hoefler wrote: On Tuesday 07 November 2006 17:10, Michael Schnell wrote: Of course, because the common concept of a timer is as asynchronous as in "multi-threaded" or even "interrupt". That is not true ! (See my other post.) Well, a timer is, even though the Delphi implementation of a so-called TTimer object might not. A TTimer by definition is what a Delphi TTimer is (and of course the Lazarus implementation is done according these lines). Of course you can do a TVinzentTimer that does a callback in a thread. In Linux this even is a very useful thing in some projects, as (other than in Windows) creating threads is very cheap here. The user needs to be aware of what he is doing and that hes required to protect resources from mutual access and that it's not possible to uses LCL functions (many of which are not thread save) in a TVinzentTimer event. Basically a timer starts, later then it expires an that expiration creates an event (in the old days we called that interrupt). This event is no way synchronous to the code currently running. As said, his is useful in some projects, but by far more difficult to use than the Delphi-like TTimer. Timer events are queued in a line (message-queue) with all "hardware"/"GUI" events. Ok. So this would do nothing more than synchronize the asynchronous event of an expired timer to the main thread. Exactly Of course, the "time" of execution of the code associated with the expiration is now determined by the time the message queue is handled the next time. You are absolutely right. (Delphi like) TTimer can't be used for "realtime" stuff. Here you need threads and taking the pain to care about mutual access problems is required and sensible. So why don't use CheckSynchronized for this? What is CheckSynchronized ? Can this help queuing multiple (e.g. Timer) events so that they get executed in order of their occurrence in a non preempted way ? To enable TTimer to work in the Delphi/Lazarus-like way, of course the main program needs to call an RTL function that never returns and _all_ actions need to be events that are queued and handled by callbacks in the sequence of their occurrence. Application.ProcessMessages needs to be in place to allow a less important event granting precedence to more important ones. -Michael

_______________________________________________
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel