[fpc-devel] Threads and alot of crap continued
mschnell at lumino.de
Tue Nov 7 11:24:03 CET 2006
>> ..., at least for the beginning !
> Why ? You don't need language enhancements for this IMHO. Scheduling and
> messaging is OS territory, not programming language territory.
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
This is just an idea I had some time ago and not yet a fully grown concept.
>> I'm sure I'll do this (supposedly in January/February), unless somebody is
>> faster than that
> I seriously doubt someone will be faster, but one never knows. But I'm
> looking forward to your contribution in this area :-)
I already tried something like that several years ago, (see below).
> TTimer is only available in Lazarus, not in FPC. It's hooked in the event
> loop, I suppose.
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.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the fpc-devel