[fpc-pascal] Re: Multi-threaded project with few locks (no Thread.waitfor). Memory consumption keeps increasing on Ubuntu 10.10 x64

[Sven Barth]

On 16.10.2010 16:47, Marco van de Voort wrote:
> In our previous episode, Sven Barth said:
>>> FreeBSD supports rfork, which has similar functionality (the subset (?)
>>> implemented by "Clone" in the linuxator is implemented by a rfork call
>>>
>>> Yrying to build on the clone call has been done in 1.0.x times, and I don't
>>> have fond memories about it.
>>>
>>
>> I did a quick check: NPTL and thus the pthreads implementation on
>> current Linux systems use "clone" as well.
>
> No doubt.
>
>> I don't know what the trouble were, but if we want a native thread
>> manager on Linux we should try "clone" again (as well as using "rfork"
>> on FreeBSD).
>
> Well, I still would have to see a good case for a native manager made. But
> one of the problems with clone was IIRC that it wasn't easily wrapped like
> other syscalls. It will need to be done in asm per architecture IIRC.
>

Right... I forgot about that...

>>>> while on e.g. Mac OS X you should rely on the c library cause the
>>>> syscall interface might be changed by Apple (@OS X devs: please correct
>>>> me if this is wrong).
>>>
>>> First we would have to get rid of "this solution in search of a problem"
>>> attitude.
>>
>> What do you mean by the "this solution in search of a problem" attitude?
>> I can't follow you currently... :(
>
> People seem to first want to bash pthreads, and discuss own threadmanagers
> before actually defining what the problem of the current solution is, and
> why it is absolutely needed to create something new.
>

One of the problem seems to be that we need to link an external library. 
While FPC allows us to do so much things with Pascal code only, we need 
to add a dependency when we want to use threading.
Note: On Windows this feels different, as here kernel32.dll is THE 
interface to the OS, while libc/pthread aren't on Unix systems (there 
the OS interface consists of the syscalls to the kernel).

> Like, euh, why simply having a thread pool to workaround slow creation is
> not a better solution (and as done for decades by vast numbers of
> programmers)
>

Maybe we should provide a generic thread pool system in the FCL? Then 
some FPC users might realize that they don't really need a faster thread 
creation.

> All I have seen is some complaint about slow starting threads by sb who can't
> even find the proper pthread source, and now we are suddenly making room for
> a native threadmanager?
>

Isn't a native threadmanager for Linux on the wishlist of FPC users for 
quite some time now? :)

Regards,
Sven