In the last episode (May 12), Scott Long said:
> Daniel Eischen wrote:
> >On Wed, 11 May 2005, Jonathan Noack wrote:
> >>I checked out _PTHREADS_INVARIANTS for libthr and libpthread on CURRENT.
> >> As far as I can tell, all but one of the defines under
> >>_PTHREADS_INVARIANTS are ASSERTs; they check for a condition and if it
> >>is false result in a fatal error. These should be very visible if
> >>they are being tripped. Only MUTEX_INIT_LINK actually *does*
> >>something. It is defined in src/lib/libpthread/thread/thr_mutex.c
> >>at lines 43-46 and in src/lib/libthr/thread/thr_mutex.c at lines
> >>44-47:
> >
> >This is way overblown and they're other areas for much better
> >optimizations than worrying about a couple of instructions. Perhaps
> >if it were called _PTHREAD_ROBUST instead of _PTHREAD_INVARIANTS,
> >noone would notice ;-)
>
> Yes, the check for the cross-linked threads libraries is still quite
> useful. However, we gave a general policy of turning off most other
> debugging and invariants tools for production releases. A good
> example is the malloc debugging options that are on in HEAD and off
> in RELENG_5. Would we be able to reach a compromise similar to that?
The malloc flags can cause serious performance issues, though, since
they basically force a memory fill before every malloc and after every
free. On the other hand, shouldn't there be a better way of detecting
cross-linked threads libraries than dieing because some internal mutex
isn't initialized? Maybe set __isthreaded to 1, 2, or 3 (or
(int)'c_r\0', 'kse\0', 'thr\0', to allow for even more threads libs)?
--
Dan Nelson
[EMAIL PROTECTED]
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
