libjava threads vs no-threads?

David Daney ddaney@avtrex.com
Mon Apr 23 04:15:00 GMT 2007


Dave Korn wrote:
> On 23 April 2007 01:53, Mohan Embar wrote:
> 
>> Hi Dave,
> 
>   Hi Mohan, thanks for answering.
> 
>>>  Here's the patch from last December that introduced ParkHelper:
>>> http://gcc.gnu.org/ml/java-patches/2006-q4/msg00246.html
>>> but I couldn't find any discussion of the no-threads case in the related
>>> conversation; I did, however, find a post from 2004 saying "Expect it to be
>>> bit-rotted".
>> I was the one who did the ParkHelper refactoring and can confirm that
>> accounting for the no-threads case wasn't a requirement for this patch
>> being accepted. 
>> The higher-ups can certainly comment more, but I was under the impression
>> that the no-threads code seems untouched and unloved in all the years I've
>> been on this list.
> 
>   That all makes sense to me.  It would make sense to tidy it up by removing
> libjava/include/no-threads.h and making configure issue a fatal warning if
> compiled without any --enable-threads option, wouldn't it?
> 

It used to work, but as Mohan mentioned has suffered bit rot.  The best 
case would be to restore it to working order.

The threads setting should default to the proper value.  If you are 
getting failures, then you are either asking for a broken configuration 
which should be fixed, or you are specifying an invalid combination in 
which case configure should be made to offer a helpful diagnostic.

It is unclear to me which of these cases you find yourself in.

David Daney



More information about the Java mailing list