40 lines
1.7 KiB
Plaintext
40 lines
1.7 KiB
Plaintext
See README.alpha for Linux on DEC AXP info. This file applies to
|
|
Linux/Intel.
|
|
|
|
Incremental GC is supported.
|
|
|
|
Dynamic libraries are supported on an ELF system. A static executable
|
|
should be linked with the gcc option "-Wl,-defsym,_DYNAMIC=0".
|
|
|
|
The collector appears to work with Linux threads. We have seen
|
|
intermittent hangs in sem_wait. So far we have been unable to reproduce
|
|
these unless the process was being debugged or traced. Thus it's
|
|
possible that the only real issue is that the debugger loses
|
|
signals on rare occasions.
|
|
|
|
The garbage collector uses SIGPWR and SIGXCPU if it is used with
|
|
Linux threads. These should not be touched by the client program.
|
|
|
|
To use threads, you need to abide by the following requirements:
|
|
|
|
1) You need to use LinuxThreads (which are included in libc6).
|
|
|
|
The collector relies on some implementation details of the LinuxThreads
|
|
package. It is unlikely that this code will work on other
|
|
pthread implementations (in particular it will *not* work with
|
|
MIT pthreads).
|
|
|
|
2) You must compile the collector with -DLINUX_THREADS and -D_REENTRANT
|
|
specified in the Makefile.
|
|
|
|
3) Every file that makes thread calls should define LINUX_THREADS and
|
|
_REENTRANT and then include gc.h. Gc.h redefines some of the
|
|
pthread primitives as macros which also provide the collector with
|
|
information it requires.
|
|
|
|
4) Currently dlopen() is probably not safe. The collector must traverse
|
|
the list of libraries maintained by the runtime loader. That can
|
|
probably be an inconsistent state when a thread calling the loader is
|
|
is stopped for GC. (It's possible that this is fixable in the
|
|
same way it is handled for SOLARIS_THREADS, with GC_dlopen.)
|