On 2012/10/12 06:00, Jeremy Evans wrote: > On 10/12 01:47, Stuart Henderson wrote: > > On 2012/10/12 04:43, Jeremy Evans wrote: > > > The io executable does not link with pthread, but some of the addons do, > > > so you need to use LD_PRELOAD=libpthread.so to use some of them > > > (including the Socket extension, probably due to its use of libevent2). > > > > Is there a downside to just forcing the executable to link with -lpthread? > > I assume it has the same downsides as linking any non-threaded program > with -lpthread. We don't do it for ruby 1.8 and perl (yet, at least).
The major downside was before rthreads where we had a problem with file descriptor blocking, I'm not aware of any problems with doing this since then. > I don't have objections for doing so, but think it's best to be > consistent with the rest of the ports tree (where we don't link > non-threaded programs with -lpthread simply because some of their > plugins use pthreads). Not sure but I think there may be some cases where we do do this. In base, we do this for httpd now - I would certainly be ok with doing this for io and ruby in ports and unless anyone knows of problems with the approach I would like to do this for Perl in base too (note, just linking the binary with -lpthread, *not* enabling actual thread support in Perl at this time). It would solve a number of problems for us (currently we cannot use any perl extensions which use a gui toolkit, or many graphic libraries such as cairo, or enable thread-safe libxml). Is anyone aware of problems which doing this might cause?
