e.g. Ada provides multithreading means as language elements and AFAIK, other languages also provide "joins" for that. I do agree that right now this should be done without any language enhancement, but in a platform independent way. Having this we will face two shortcomings: 1) following the Delphi ways we have a message scheduler for the main thread (GUI thread in Delphi) but not for the worker threads created by TThread. This "asymmetrical" approach makes using threads a bit clumsy. Once we provide a standard means to send messages to a thread we will want to allow a worker thread react on a message like the main thread: by firing an event and by using "Application.ProcessMessages" (so here we would have a TThread.Application property). The TThread.Execute thus would (optionally) be enabled to finish without ending the thread. This enhancement can be done without enhancing the language at all. 2) With that solution of (1) we would have a new thread model that now follows the event driven programming paradigm like the main thread does. With that we would want to integrate the thread programming more tightly and more easy to use in the language. Here I would like to see a means to create "thread events". With that I mean a way to create "callback" properties for classes that not just provide a function call but can be defined (either statically with the class implementation or dynamically when fired) to run on a certain thread context. This would of course mean sending a message with the parameters to the thread, queuing it, and have the thread execute it once it's free to do so. The "calling" thread should optionally be made waiting for the called thread to do it's thing (like with "Synchronize", but more versatile as parameters can be passed"). In that case a function result and "out" parameters can be used. This is just an idea I had some time ago and not yet a fully grown concept. I already tried something like that several years ago, (see below).
Ah ! At that time I did get it running in Lazarus and was struck, as it did compile but not work without. That's really bad ! IMHO it should be possible to use TTimer and TThread in a simple non-GUI way. (I maybe will need to do an embedded project on an ARM/Linux system that does not have X or any widget library.) What is the problem with that ? can we work together on making this happen (e.g. extracting a part of the "Application" code from Lazarus, but doing it's own event loop instead of using the OS for that.) I already tried (and contributed) some thing like that several years ago (creating my own Application object and trying to provide most of the Delphi thread primitives for Linux), but at that time all this was bound to fail, as the memory management was not thread save :-( . (Lazarus was not started at that time AFAIK.) -Michael |
_______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
