Subject: Re: galeon is failing on 1.6R
To: Nathan J. Williams <nathanw@wasabisystems.com>
From: Steven M. Bellovin <smb@research.att.com>
List: current-users
Date: 04/22/2003 16:01:18
In message <mtur87umhq0.fsf@contents-vnder-pressvre.mit.edu>, "Nathan J. Willia
ms" writes:
>"Steven M. Bellovin" <smb@research.att.com> writes:
>
>> My concern is not for any one easily-fixed bug, but whether there are 
>> enough of them out there that we can't patch everything.
>
>That is possible. I could make them a compile-time option (I think a
>run-time option might hurt performance), and investigating that is on
>my to-do list. My fear with making such assertions optional, though,
>is that nobody but me would ever use them.
>
>One of the reasons I made this change was to try to nail down whether
>some of the things that have broken with native pthreads are tripping
>over pthreads bugs or just having their own bugs exposed; this makes
>the latter much more obvious when it happens.

Now is definitely not the time to do anything like that; let's first 
find out how bad the problem really is.  It may indeed be bad enough -- 
witness some of the bug compatibility in xterm and in X servers.

One easy way to make the assertions optional is to say something like

	assert(_Disable_Thread_Bug_Checks || (realtest));

where _Disable_Thread_Bug_Checks is some initialized static variable.  
It's a very easy source (or executable) patch to disable the assertion, 
if someone has some application that (mostly) runs despite its inherent 
bugginess.  

Put another way, if I can't get some application fixed, my choice may 
be to accept occasional crashes because the application's thread code 
is broken, or to have it not run at all because of the assertion.  


		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)