diff options
Diffstat (limited to 'gc/README.linux')
| -rw-r--r-- | gc/README.linux | 50 |
1 files changed, 0 insertions, 50 deletions
diff --git a/gc/README.linux b/gc/README.linux deleted file mode 100644 index b4f136a..0000000 --- a/gc/README.linux +++ /dev/null @@ -1,50 +0,0 @@ -See README.alpha for Linux on DEC AXP info. - -This file applies mostly to Linux/Intel IA32. Ports to Linux on an M68K -and PowerPC are also integrated. They should behave similarly, except that -the PowerPC port lacks incremental GC support, and it is unknown to what -extent the Linux threads code is functional. - -Incremental GC is supported on Intel IA32 and M68K. - -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.) - -5) The combination of LINUX_THREADS, REDIRECT_MALLOC, and incremental - collection fails in seemingly random places. This hasn't been tracked - down yet, but is perhaps not completely astonishing. The thread package - uses malloc, and thus can presumably get SIGSEGVs while inside the - package. There is no real guarantee that signals are handled properly - at that point. |