weak implementation of threads has problems - kse fix attached
Joe Marcus Clarke
marcus at marcuscom.com
Tue Jun 8 05:24:56 GMT 2004
On Tue, 2004-06-08 at 01:21, Scott Long wrote:
> Joe Marcus Clarke wrote:
> > On Tue, 2004-06-08 at 00:32, Daniel Eischen wrote:
> >>On Mon, 7 Jun 2004, Sean McNeil wrote:
> >>>Up front, I'd like to make a few apologies:
> >>>1) I am sorry for the length of this email.
> >>>2) Although some very valid opinions have been expressed, I respectfully
> >>>have to disagree. This email will hopefully strengthen my position.
> >>Please stop spamming multiple lists.
> >>No, I don't want to litter all our thread libraries with strong references.
> >>As I've said before, build your shared libraries correctly so they don't
> >>bring in the threads library.
> > In order to do this, I'm a strong proponent of making -pthread the
> > default PTHREAD_LIBS from 4.X and 5.X. This will do the right thing in
> > all cases, and reduces diffs among branches. What is keeping this from
> > happening from a threading standpoint?
> > Joe
> If you're going to change default behaviour like this then you need to
> do it before 5.3 and live with the change for the entire life of 5.x.
> I oppose changing it in 4.x.
Right, this would only be a change for 5.X, and would make it identical
to 4.X. -pthread works for 5.X right now, and will link executables to
libpthread. Shared objects will only use libpthread to resolve symbols
PGP Key : http://www.marcuscom.com/pgp.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/freebsd-gnome/attachments/20040608/3977e6c1/attachment.bin
More information about the freebsd-gnome