[fpc-devel] Threads and alot of crap continued

[Michael Schnell]

>> ..., 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 
be used.

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.)

-Michael
 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20061107/fe4ee0eb/attachment.html>