[gclist] Thread safe GC

[Charles Fiterman]

>- pthreads are not sufficiently cooperative.  (Many pthreads implementations
>are, however.)  My impression is that win32 threads are adequate, but only if
>you rely on obscure information that's not apparent from the documentation.
> (I.e. the situation is basically the same as with pthreads, but there are only
>two implementation that anybody cares about, and they come from the same
>vendor.)

The debug versions of thread libraries are generally cooperative enough
but the normal versions are not. My definition is as follows.

If I can't stop and restart threads I'm totally stuck. I can't really
collect for running threads.

If I can't get the true stack boundaries I have a very poor quality of
implementation. I have to scan the whole stack for every thread and while
zeroing parts of the stack helps this is always inefficient.

IHMO the correct way to do threads is with continuations. Execution frames
are simply collectible objects. This results in a far more flexible language
and threads are done right very simply. 

Making execution frames full scale objects can eliminate the distinction 
between function calls and constructors. A constructor is simply a function 
call that returns a pointer to its execution frame. The difference is how 
it is used not what it is. Allowing messages after parameter pushing and 
after body execution simplifies syntax. We have something we call an export
parameter which means its message name is pushed onto the name scan path
after parameters are pushed. 'if' is simply the name of a function and
'else' and 'elseif' are export parameters of 'if'. Partial evaluation makes
it efficient where it can.
			-  
Charles Fiterman		Geodesic Systems
414 North Orleans Suite 410	Phone 312 832 1221 x223
Chicago IL 60610-4418		FAX   312 832 1230
				http://www.geodesic.com

A computer language without garbage collection
  is like a city without garbage collection.