------- Additional Comments From gniccolai at yahoo dot com 2005-02-24 11:00 ------- (In reply to comment #18) > I think this is a waste really for this bug to be open as non of the GCC people commented on it and > when the orginal bug was filed, there was a huge opportunity to talk over this and nothing was done. > > So I am going to close as will not fix.
Is there any of the GCC people in the POSIX committee working at the PTHREAD sub-standard? Because David Butenhof (member of the above and writer of the book "Programming with POSIX® Threads") has strongly argued against this feature: <cite> Obviously, (excessive) locking does NOT allow for simultaneous execution. A lot of people are used to write old good ST code and "add some locks to make it thread-safe" afterwards. The realworld result is always frustrating: the application is terribly slow and doesn't scale. Sure, we need some synchronization primitives (such as mutexes) to implement inter-thread communication. As a rule, thoroughly designed MT application is a set of fully independent threads which communicate via the message queues. The synchronization primitives are used inside these queues and virtually no locks are supposed outside the queues. But what we see in real life is herds of mutexes spread across the code. "MT-aware classes" try to lock almost every method... And even more, some "industrial-strength" PLs have the built-in mutex per every object! IMHO there is no excuse for this madness. </cite> I have found no other competent opinion arguing the other way around (that is, the thing that you want to do); every competent opinion is in this direction. The ABI closure is actually based on a non-standard solution, and on a "lack of interest" (and presumabily competence) in this field. Also, a bug cannot be considered closed "because no-one protested yet". BTW; I am going to see Stallman today and speak with him about this fact. Is in Milan today. Bests, Giancarlo Niccolai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20099