Newsgroups: comp.lang.smalltalk,comp.lang.scheme,comp.lang.lisp
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!news.sei.cmu.edu!cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!pipex!uunet!sytex!smcl
From: smcl@sytex.com (Scott McLoughlin)
Subject: Re: Multithreading
Message-ID: <51kwVc2w165w@sytex.com>
Sender: bbs@sytex.com
Organization: Sytex Access Ltd.
References: <3adnkn$jv4@sand.cis.ufl.edu>
Date: Wed, 16 Nov 1994 21:47:03 GMT
Lines: 23
Xref: glinda.oz.cs.cmu.edu comp.lang.smalltalk:18048 comp.lang.scheme:11328 comp.lang.lisp:15658

kem@prl.ufl.edu (Kelly Murray) writes:

> It's not that different than just making your library routines "thread safe".
> Symbol properties are a little special because they are used by the system it
> and thus you can't depend on users not screwing them up.
> CommonLisp defines access to a symbol plist as a real list of cons cells
> that can be destructively modified without regard to any locking.

Howdy,
        In what way are symbol properties "used by the system"? CL's
SYMBOL-PLIST and (SETF SYMBOL-PLIST) - which you mention - would, I
think, encourage system implementors to _not_ have property lists
"used by the system". I'd think hash tables for various system 
namespaces would do just as well, if not better. My LinkLisp caches
a per-symbol 16 bit hash code computed during MAKE-SYMBOL to 
"encourage" use of hash tables with symbol keys.
        Of course, the locking issues would remain with the hash
tables. Just my two cents.

=============================================
Scott McLoughlin
Conscious Computing
=============================================
