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

[Marco van de Voort]

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.

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

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)

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? 

A bit premature IMHO.