[fpc-devel] Threading support and C library under Linux/Unix

[Jonas Maebe]

On 22 Jun 2010, at 15:01, Henry Vermaak wrote:

> On 22 June 2010 13:55, Michael Van Canneyt <michael at freepascal.org>  
> wrote:
>>
>> The problem starts if you start linking to C libraries. In that  
>> case you're
>> pretty much forced to use pthreads;
>
> Why is that?  I thought you could use anything, as long as it's  
> posix compliant?


Delphi and FPC both implement memory managers with the same API. That  
does not mean that as a result you can allocate a memory block in FPC  
code, pass it to a Delphi-compiled DLL and free it there.

A libQt compiled against libpthread.so will continue using  
libpthread.so, even if your FPC program includes its own POSIX- 
interface-compliant thread manager. Even if you add "packages" support  
to FPC so that you can turn both the FPC RTL and this FPC thread  
library into independent shared libraries, you're not yet home free  
since both this FPC threadlib and libpthread will export symbols with  
the same name. Depending on how the symbols are resolved,
a) the C code may keep using the libpthread functions and your Pascal  
code the FPC threadlib functions, in which case there is just as much  
interoperability as with the memory manager case above (that's what  
would happen on Mac OS X unless you force the dynamic linker to use a  
flat namespace, but not all programs work when run that way)
b) the C code and Pascal code may both use a mix of symbols from both  
libraries, which is even worse than case a) (I think that this can  
happen on Linux under certain circumstances)
c) the C and Pascal code may both use all *common* symbols from either  
lipthread of the FPC threadlib, but then there's still the case of  
symbols that are not common. Even if you implement every single  
function from POSIX, all platforms I know of also have extra  
pthread*_np functions (such as pthread_kill_other_threads_np() on  
Linux -- the np stands for "not portable") that only exist on some  
platforms. So you'd also have to implement all of these extra  
functions per platform (and such functions get added/removed from time  
to time).

I propose that if someone wants to write this: try and see how it  
works out. We can include such a thread manager in the FPC packages if  
it works and if someone guarantees that they will support and maintain  
it for the foreseeable future.


Jonas