[fpc-devel] Threads and alot of crap

[Michael Van Canneyt]

On Mon, 9 Oct 2006, Ales Katona wrote:

> I've had the "honor" of looking at current TThread/pthreads/cthreads
> implementation in unix (FreeBSD to be precise) and found it extremely
> bad.

About the TThread: this is known.

We should have one (and only one) TThread implementation which is 
OS-Independent, and which uses ONLY thread functions from the system unit.
(and hence from the threadmanager)

> 
> Not to criticize, I'm here to ask for permission/toughts on adding a few
> standard methods to TThreadManager.
> 
> I would like to add semaphore functions to it, to be able to use them in
> Classes/TThread implementation. The reason for this is, that Classes is
> compiled BEFORE pthreads and as such I cannot use pthreads directly (and
> shouldn't for linking issues to libc) to implement threading in TThread.

Permission granted (if it is mine to grant), provided you
add it for all platforms which currently have threads.

> 
> I see basicly 3 approaches:
> 
> 1. add semaphore/mutex functions to TThreadManager record

This is best.

> 2. add a new "semaphores" record

They will not be used independen of TThreads, so I see no use for this.

> 3. move the TThread - threading specific functions out of tthread and
> into a "TThreadTThreadManager" kind of thing. Eg: "start thread with
> this callback" and such which are currently used in tthread.inc

Nono, just expand the current thread support.
Although I'm surprised you need to add stuff, in principle it should have
everything to work for TThread...

> 
> Not sure which one is best..
> 
> Another thing.
> 
> I noticed that FreeBSD has 3 implementations of pthreads.
> 
> libpthread, Libc_r (reentrant) and "libthr" (1:1 kernel threads).
> 
> Currently fpc does some sort of automagical "descision" between libc and
> libpthread. I think users should be able to specify this somehow.

The linker currently decides this, and there is no way to 'specify' this
except of dynamically loading the library, which is kind of a loop, since
libc must be loaded in order for dynlibs to work.

> 
> I've cleaned up unices I know off old {$IFDEF Linux} but I also want to
> add proper threading and remove the idiotic pipe/semaphore hack.

Absolutely. In principle, TThread should be implemented in a system-independent
way. The system unit thread support should be made complete enough to enable
you to write TThread in a system-independent way.

Michael.