Newsgroups: comp.lang.smalltalk,comp.lang.scheme,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!nntp.club.cc.cmu.edu!hudson.lm.com!news.pop.psu.edu!news.cac.psu.edu!howland.reston.ans.net!gatech!newsxfer.itd.umich.edu!zip.eecs.umich.edu!newshost.marcam.com!charnel.ecst.csuchico.edu!waldorf.csc.calpoly.edu!kestrel.edu!mcdonald
From: mcdonald@kestrel.edu (Jim McDonald)
Subject: Re: Multithreading
Message-ID: <1994Nov16.202444.9500@kestrel.edu>
Sender: mcdonald@kestrel.edu (Jim McDonald)
Organization: Kestrel Institute, Palo Alto, CA
References: <CyyHLD.BIo@world.std.com> <hbakerCyyn4I.8p0@netcom.com> <DAVIS.94Nov16111415@passy.ilog.fr>
Date: Wed, 16 Nov 1994 20:24:44 GMT
Lines: 52
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:18040 comp.lang.scheme:11324 comp.lang.lisp:15651


In article <DAVIS.94Nov16111415@passy.ilog.fr>, davis@ilog.fr (Harley Davis) writes:
|> 
|> In article <3ab0gt$ibl@sand.cis.ufl.edu> kem@prl.ufl.edu (Kelly Murray) writes:
|> 
|>    Stack management makes life hard -- you must allow stacks to grow !
|>    You can't just punt like C-threads and only allow fixed-sized
|>    stacks.  This essentially requires that you can relocate stacks
|>    into different addresses.
|> 
|> Why is this more important in Lisp than in C?  Is it a question of
|> doing the right thing or is there a deeper motivation?

Two reasons come to mind:

  * Lisp programmers invest more in their execution environment, and 
    scream bloody murder if their 5 day old lisp session crashes for
    a preventable reason, whereas C programmers expect their programs
    to die mysteriously from time to time, and plan accordingly.

  * If you are running some particular task on a given stack, and you
    know that particular task needs very little stack, in C you can 
    be fairly certain that a fixed stack will work, but in Lisp the
    user can invalidate your assumption at runtime.  For example, they
    might interrupt the task, run a debugger, the compiler, some test
    code etc. on the remaining stack, then resume the interrupted task.


I've been burned several times by an unnamed (but not Lucid :) lisp 
implementation that crashes when I accidentally run a large compilation 
in a process stack that was intended for something like a mouse handler.
It's incredibly aggravating.

|>    Locks and Synchronization.  What happens when two processes
|>    change/add/remove a symbol's property at the same time?  Let the
|>    property list just get munged?  Maybe the C people would say OK,
|>    but not in Lisp.  I added a "synced" symbol properties (not Common
|>    Lisp).  Also hash-tables must be synched, and packages for
|>    interning symbols, and probably other stuff I can't remember.
|> 
|> Why are these items handled differently than other shared resources,
|> where I suppose you would use a locking or semaphore mechanism?

When we implemented QLISP, Lucid's source code had to be extensively
modified to put locks all over the place (hundreds of places).  I don't
remember any one low-level thing such as property lists needing any 
particular attention beyond that, except perhaps for consing.  But 
this was about 5 years ago, so my memory could be faulty.  I remember
that the compiler was particularly resistant to re-entrancy, but I 
think that was just a matter of us not taking the time to properly 
lock everything it used.

