[BACK]Return to README.linux CVS log [TXT][DIR] Up to [local] / OpenXM_contrib2 / asir2000 / gc

Diff for /OpenXM_contrib2/asir2000/gc/Attic/README.linux between version 1.1.1.1 and 1.2

version 1.1.1.1, 1999/12/03 07:39:09 version 1.2, 2000/12/01 09:26:10
Line 31  To use threads, you need to abide by the following req
Line 31  To use threads, you need to abide by the following req
 2) You must compile the collector with -DLINUX_THREADS and -D_REENTRANT  2) You must compile the collector with -DLINUX_THREADS and -D_REENTRANT
    specified in the Makefile.     specified in the Makefile.
   
 3) Every file that makes thread calls should define LINUX_THREADS and  3a) Every file that makes thread calls should define LINUX_THREADS and
    _REENTRANT and then include gc.h.  Gc.h redefines some of the     _REENTRANT and then include gc.h.  Gc.h redefines some of the
    pthread primitives as macros which also provide the collector with     pthread primitives as macros which also provide the collector with
    information it requires.     information it requires.
   
 4) Currently dlopen() is probably not safe.  The collector must traverse  3b) A new alternative to (3a) is to build the collector with
    the list of libraries maintained by the runtime loader.  That can     -DUSE_LD_WRAP, and to link the final program with
    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.)  
   
      (for ld) --wrap read --wrap dlopen --wrap pthread_create \
               --wrap pthread_join --wrap pthread_sigmask
   
      (for gcc) -Wl,--wrap -Wl,read -Wl,--wrap -Wl,dlopen -Wl,--wrap \
                -Wl,pthread_create -Wl,--wrap -Wl,pthread_join -Wl,--wrap \
                -Wl,pthread_sigmask
   
      In any case, _REENTRANT should be defined during compilation.
   
   4) Dlopen() disables collection during its execution.  (It can't run
      concurrently with the collector, since the collector looks at its
      data structures.  It can't acquire the allocator lock, since arbitrary
      user startup code may run as part of dlopen().)  Under unusual
      conditions, this may cause unexpected heap growth.
   
 5) The combination of LINUX_THREADS, REDIRECT_MALLOC, and incremental  5) The combination of LINUX_THREADS, REDIRECT_MALLOC, and incremental
    collection fails in seemingly random places.  This hasn't been tracked     collection fails in seemingly random places.  This hasn't been tracked
    down yet, but is perhaps not completely astonishing.  The thread package     down yet, but is perhaps not completely astonishing.  The thread package
    uses malloc, and thus can presumably get SIGSEGVs while inside the     uses malloc, and thus can presumably get SIGSEGVs while inside the
    package.  There is no real guarantee that signals are handled properly     package.  There is no real guarantee that signals are handled properly
    at that point.     at that point.
   
   6) Thread local storage may not be viewed as part of the root set by the
      collector.  This probably depends on the linuxthreads version.  For the
      time being, any collectable memory referenced by thread local storage should
      also be referenced from elsewhere, or be allocated as uncollectable.
      (This is really a bug that should be fixed somehow.)
Legend:
Removed from v.1.1.1.1  
changed lines
  Added in v.1.2
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>