Re: Removing scm_root_state

[Richard Guenther <richard dot guenther at student dot uni-tuebingen dot de>]

Hi!

As the topic of global variables pop up, what I wanted for a long time
now is the ability to boot multiple VMs in different threads, so I propose
to get rid of the global variables entirely and provide api functions
which take a sort of a VM-struct as first argument. Backwards
compatibility can be obtained by doing the current api as macros which
just pass a global VM-struct as first argument.

Comments? Richard.

On Tue, 21 Mar 2000, Mikael Djurfeldt wrote:

> I'd like us to remove the scm_root_state structure.
> 
> I'd like us only to have four possible semi-global scopes: global, per
> thread, per print-call-chain, and per read-call-chain (I'll return to
> this in a separate post).
> 
> I don't think we need a "per root" in addition to the above.
> 
> There is a planned reorganization of the threads support which aims to
> remove the --with-threads option.  The choice of whether to use
> threads or not, and, especially, which threads package to use, should
> be made by the application author, not by the system administrator.
> 
> With this change, there will be a structure of function pointers,
> `scm_thread' which will have default non-thread values until an
> application has "plugged in" a particular threads package (one of
> which will be COOP and another POSIX).  This means that the
> scm_thread.getspecific/setspecific abstraction always will be
> available, also under non-threaded use.
> 
> Suggestion:
> 
> Change the scope of variables in scm_root_state to "per thread" and
> use scm_thread.getspecific/setspecific to implement them.
> 
> Protests?
> 
> Comments?
> 

--
Richard Guenther <richard.guenther@student.uni-tuebingen.de>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/