Updates from 0.2.1 into 0.2.1-inu-1.5release-0-2-1-inu-1-5

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.