DragonFly kernel List (threaded) for 2008-12
DragonFly BSD
DragonFly kernel List (threaded) for 2008-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Threading libraries

From: Hasso Tepper <hasso@xxxxxxxxx>
Date: Sun, 14 Dec 2008 09:08:10 +0200

Justin C. Sherrill wrote:
> On Sat, December 13, 2008 4:35 pm, Hasso Tepper wrote:
> > Justin C. Sherrill wrote:
> >> What would this mean for the 2.2 release?
> >
> > It would be OK, but ... I'm concerned about the fact that features
> > specific to libthread_xu (for example barriers) haven't got any
> > testing so far, but these will be used by third-party apps if libc_r
> > will be removed. I don't feel comfortable doing this move so close to
> > release, so I'd prefer post 2.2 move.
> How can we test?  I'm doing a pbulk build using the _xu library on
> Matthias's system right now, but I'm guessing we would have to actually
> be executing the binaries to find out what works and what doesn't.

We can test by removing libc_r only, that's the point.

> >> Would people who had been upgrading from pre-xu versions need to
> >> recompile everything, including pkgsrc apps?
> >
> > This isn't acceptable IMHO. libpthread.so wrapper should stay.
> If I recall correctly, _xu is the default on new installs, so the
> number of people who use/need c_r is declining over time.  At some
> point, people using the old library will have to stop and recompile,
> somehow, won't they?

It's default, but function implemented only in it can't be used by 
applications unless implemented also in libc_r. That's how our threading 
libraries switching works.

There is also the question how we should remove libc_r. Preserving the 
libpthread.so wrapper or not?

Hasso Tepper

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]