Re: Considering Guile as part of a Master's Thesis

[Clifford Beshers <beshers@cs.columbia.edu>]

   From: "Paul R. Wilson" <wilson@cs.utexas.edu>
   Date: Fri, 19 Dec 1997 09:38:04 -0600
   X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96)
   Cc: Mikael Djurfeldt <mdj@nada.kth.se>, peyler@nortom.com, bkuhn@ebb.org,
	   guile@cygnus.com, gss@nortom.com
   Sender: owner-guile@cygnus.com
   Precedence: bulk
   Content-Type: text
   Content-Length: 2534

   >From owner-guile@cygnus.com Fri Dec 19 07:35:06 1997
   >To: Mikael Djurfeldt <mdj@nada.kth.se>
   >Cc: peyler@nortom.com, bkuhn@ebb.org, guile@cygnus.com, gss@nortom.com
   >Subject: Re: Considering Guile as part of a Master's Thesis
   >
   >Mikael Djurfeldt <mdj@nada.kth.se> writes:
   >
   >This reminds me - I /think/ I read somewhere about pretty good gengc
   >that was also conservative.

   ...

   This seems like a very doable little project.

   The trickier part is making the generational GC thread safe.  You
   need to make sure that the allocator and write barrier work right in
   the presence of whatever kind of threads you use.  This is a non-problem
   for RScheme because we use a "safe points" scheme for thread switching;
   threads never switch except at places that are non-confusing for
   the GC.  If you may have thread switches at any instruction, you
   have to deal with synchronization issues.  I don't think these
   issues are actually hard, either, but we haven't done them.

   The main thing you want to do is replicate the data structures
   that are frequently operated on, so that threads can usually
   allocate and record write barrier events without synchronizing.


Though perhaps trickier, this job is at the top of my priority list
for guile development.  I realize that my list is probably different
from everyone else's, but I still think it would be a good idea, and
here's why.

I'm using Guile as the extension language, actually the primary
language, in a real-time graphics application for research.  Paul
Wilson's real-time garbage collection would be a real help, I think.
Others in my group are using Modula-3, which has real-time garbage
collection under Windows NT and Solaris, and it is really nice not to
have the graphics jerk to a halt every n seconds.  If this could be
worked in with support for kernel threads, that would be really great.

If Guile is to succeed as an extension language, it really should have
full access to the facilities provided by the operating system.  This
is already coming along nicely with SCSH support, but we need more.
Multi-processors are becoming more common, and most operating systems
now provide, or will soon provide, good kernel thread implementations,
because they make it relatively simple to write parallelizable
programs.

Support for different languages syntaxes implemented in Guile is
interesting, but can really be done mostly independently of
development of the guile core, it seems to me.

Similarly, an object system would be nice, but faced with a lack of a
standard, I expect that this will be a headache for a long time.

Real-time GC and kernel thread support would really widen the class of
programs which could be implemented effectively in Guile, and it will
be easiest to put in sooner, rather than later, I think.

Cliff

-- 
Clifford Beshers                     Computer Graphics and User Interfaces Lab
beshers@cs.columbia.edu                         Department of Computer Science
http://www.cs.columbia.edu/~beshers                        Columbia University