Subject: Re: disabling PTHREAD_CONCURRENCY for 3.0
To: Hubert Feyrer <email@example.com>
From: Chuck Silvers <firstname.lastname@example.org>
Date: 12/12/2005 09:22:55
On Sun, Dec 11, 2005 at 05:54:46PM +0100, Hubert Feyrer wrote:
> On Sat, 10 Dec 2005, Chuck Silvers wrote:
> >since the code triggered by setting PTHREAD_CONCURRENCY causes
> >library aborts and kernel panics, I'd like to disable it for 3.0
> >since it doesn't appear that it can be fixed in time.
> The variable was available in previous releases, how do you intend to
> handle backward compatibility?
it was just as broken in previous releases, it shouldn't have been enabled
there either. as I've said earlier, it's pretty obvious from the comments
and the code that this feature (the PTHREAD_CONCURRENCY part of our pthread
implementation) was never finished.
> I'd rather keep it, with a default of 1. This allows users to still set it
> higher and debug things.
the problem is that it's known to cause crashes. users will not want to
debug things, only developers. since it won't be fixed in time,
it seems better to disable the feature. developers will likely be using
-current, and I'm not proposing to disable it there.
I've been under the impression that PTHREAD_CONCURRENCY is so broken that
it's unusable, but maybe I'm wrong about that. has anyone actually been
setting PTHREAD_CONCURRENCY to something greater than 1 and had it work
reliably for a real application? if so, we could just document that it's
known to be buggy and likely to crash your machine and leave it enabled,
but that seems pretty lame.