We do all of that in linux-threads.  Somebody needs to debug it though
and I don't have the time.

	- Godmar

> 
> This may not be entirely relevant, or it might.
> 
> For any port using native threads, the following must be considered:
> 
> 1. When the GC thread does a GC, no other threads may run.  This is because
>    if the GC thread gets preempted, then another thread may create a
>    reference to an object by modifying memory that the GC has already walked.
>    If the GC sees no other reference to this memory, then it will be freed,
>    even though there is a reference to it.
> 
>    AmigaOS provides Forbid() and Permit() which nicely block other threads
>    (as well as all other threads in the system, ugh).
> 
>    POSIX threads provides no adequate facility.
> 
> 2. The GC thread must also walk the register files of sleeping threads, since
>    in a JIT system, the only reference to an object might be in a register.
>    This requires that the GC have some knowledge of how registers are stored
>    on the native thread system (typically, registers are stored on the stack).
> 
>    Systems that do thread switching entirely in the kernel, and place the
>    registers on the kernel stack, will not work out here, since the user-land
>    GC has no way of reading kernel memory.
> 
> If these issues are not addressed, then subtle GC bugs may occur.
> 
> Note that if you are running your own thread package, tending to these is
> easy, since you can provide the necessary functionality.
>