Hi,

In message "[ruby-talk:13224] Re: Native/pthreads in Ruby [Long]"
    on 01/03/27, Marc Butler <mlb / noworkingparts.com> writes:

|Certainly a global interpreter lock would achieve the synchronization necessary
|to run the mark-sweep collector.  It seems natural to place this lock in the
|memory allocation routine, so that only threads that are attempting to allocate
|memory are locked during garbage collection.

Well, that makes lock granularity much smaller than one giant lock.
But Ruby internal is not thread safe in general.

|I am curious as to why ruby uses a conservative collector.  I know that Ruby is
|a type-less language but I would have thought the run time structures used by
|the interpreter would provide enough information to avoid the need of the
|collector.  I am only just learning about garbage collection, and have not
|developed any intuition about such systems.

Well, conservativeness is due to ease of extension writing.  You don't
have to protect your local C variables in extensions (and builtin
methods too).

|I had imagined that it might be possible to implement a thread oriented
|collector using the concepts that drive a generational collector.  If we ignore
|thread recycling for convenience, threads often fall into two categories:
|short-lived work threads that perform specific tasks; and long-lived threads
|that handle blocking system calls (like I/O).  By using the thread id like a
|special reference you can dereference all the data allocated in that threads
|lifetime, if other threads now have references to that data it will still be
|safe.

Interesting.  Threads share object space so that objects are not
belong to any specific thread.  But there might be a solution.  

The other obstacle is pthread does allow retrieving stack address only
at the creation time.

FYI, Bohem GC wrap pthread_create(), Qscheme using thread signal
handler to get stack addresses.  OCaml uses assembler code to get
stack boundary of each invoked C function.

							matz.