More Tru64 errors

Mon Dec 10 10:20:00 GMT 2001

> > Maybe it should just define GC_LINUX_THREADS (which should 
> really be 
> > renamed GC_POSIX_THREADS) and hope that it works?
>> That might be a good strategy for the trunk.
>That assumes a somewhat harder goal than what I have had in mind. My goal
has been to have linux_threads.c work on all pthreads platforms. (It's not
even clear that's achievable, since it may involve performance regressions
on Solaris, even if it works reliably.)
But I have still been assuming that there would be some small amount of
conditionally compiled code platform dependent code in linux_threads.c.
Thus GC_LINUX_THREADS and GC_OSF1_THREADS wouldn't compile exactly the same
code. Thus linux_threads.c should ideally be renamed to something like
pthreads.c, but there would still be distinct macros for different threads
implementations. It might be possible to avoid that. But currently the
macros are definitely still used.
In particular, if GC_LINUX_THREADS is defined, code to read /proc/stat is
compiled in. (This is a workaround for a sysconf bug which has since been
fixed, but probably still exists in some distributions.) This code is very
unlikely to work on a non-Linux platform.
I'm not really sure it's a good idea to change this. The odds of this code
working reliably on an untested platform are pretty low. (I think my
success rate at this is 0 so far. The OSF1/Tru64 case is somewhat special,
since it was derived from code that was reported to work, but wasn't
structured in quite the way I intended.) I ususally need to at least work
around some interesting feature. It has also been a good test case for
finding pthreads library bugs. I think we want to make it obvious if you're
building on an untested platform. An easily repairable build failure is
probably a good thing, so long as the collector is not built by default.
Hans