In our previous episode, Sven Barth said: > >>> 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.
Yes. So all your programs don't use any libraries except libc because pthreads? If so, what kind of programs do you make? > 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). I don't see it that way. I'm perfectly happy to take libc/pthread as system interface. If they actually went to the trouble to make it a decent API, somewhat stable in time, and decoupled from e.g. compiler version changes. THAT is the *nix problem, not the name of the library, be it user32 or libc or libroot. Still, while I agree with the problem, I don't think a native threadlib will change anything in this picture. The amount of pain won't lessen. One only adds yet another factor (libc threads vs pascal threads) to the chaos. The only possible thing is wait till Linux and the Unix world at large comes to its senses. > > 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. I think all sane contributions are welcomed. One can never fully exclude that somebody might actually come up with both a good Pascal only threading library and a good motivation to actually use it. ( I can imagine some limited uses to really quick initialize CGIs or so) But talking about making room in the FPC implementation before these two conditions are satisfied, just because some people think there is a problem, and a solution for that problem. It will just lead to orphaned attempts and a drain on FPC resources. Just look at the discussion about the current TThread implementation, which afaik stems from the 2003-2004 timeframe (when what is now the 2.x series was finalized in the 1.9 beta series). And that is just library usage. How long do you think it will take to get a native implementation up to snuff for real use, beyond being some minimalists pet project ? Even if I forget for the moment that it is DOA out of principle (since it won't play nice with external libs probably), it would take years. And all the while the forces concentrate on that, the current implementation is on ice, waiting for the glorious new code that will fix everything and will never come. Better invest in dressing up the current implementation, synchronization features (syncobjs, TMonitor, locked queues etc), stuff that is really going to be used. Less glory, more result. > > 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? :) Not mine. And yes, there has been a lot of echoing of sentiment, but I never saw a decent problem definition, and what a native solution would actually fix. The native threadlib has been a recurring topic since the 1.0.x implementation was trashed, which surfaces at any possible problem in the current thread implementation (which is blown out of proportion to make a case for "start over"). _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
