I kind-of understand that... Borland tried to encapsulate the whole
threading thing in a TThread class. It made it easier and every bit
helps!
Agreed.
But while the current implementation is absolutely appropriate for many
tasks, it _could_ be a lot more usable if in many other cases when using
a different paradigm.
TThreads don't have an event queue and thus while in the main thread you
do "event driven programming" (doing multiple "run to completion" code
snippets that are fired by certain events), while the TThreads only can
run as a "one shot" or in a cycle. Giving each thread an event queue
could make the thread programming more transparent to the "average"
programmer, as the same paradigm could be used in the main thread and
the "worker threads"
An even more advanced way would be combining the paradigms of event
driven programming and threaded projects by introducing "thread events".
I.e. when an event is fired, it can use an additional thread (and thus
an additional CPU) instead of running as a subroutine of the code that
fires the event.
-Michael
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
