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