On Fri, 11 Mar 2011, Jeremy Evans wrote: > Well, if what you're doing messes with fds in a way that breaks when > linked with -lpthread, then it won't work. However, if your code > doesn't do things with fds, it will work fine. For example, I have a > graphical file renaming program that uses qtruby. I've never > experienced an issue with it using either the LD_PRELOAD hack or linking > with -lpthread. For me, the software works fine and meets my needs.
Sure but you cannot garantee other softwares will not also use qtruby in the future. You have to realize libpthread turns all the file descriptors to non-blocking mode and you may end up with wrong results and get an EINTR. e.g. libc open(2) versus pthreads(3) open. > Basically, linking with -lpthread causes the exact same issues that > using the LD_PRELOAD hack will cause. All it does is save the user from Obviously. > having to modify the calling program's environment. So the question > really becomes, should we have such software at all in the ports tree? Exactly, and this is the reason I disable p5-Glib2 altogether. > As I see it, linking with -lpthread is superior to using the LD_PRELOAD > hack in every way. So we should either link with -lpthread or mark the > port BROKEN as you did with devel/p5-Glib2. In the case of importing > new software that has this issue, it should either be imported using > -lpthread, or it should not be imported at all. > > > Again as I said, it's just me, maybe others disagree. Also several of us > > spent quite some time moving hundreds of ports from using -lpthread into > > using -pthread (not all were done though). > > And for most programs, -pthread is correct. The only known cases where > -lpthread is necessary are for native extensions for interpreters that > don't link with -pthread (e.g. perl, ruby, tcl). This is by design, using -pthread will only link binaries with pthreads(3). That said, I'm not experienced enough in threads to go any further, maybe one of our threads guys could extend on that. -- Antoine
