| 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.) |