> Ah, but gethash is not read-only in SBCL, even if it is read-only > from the point of view of the application.
In which case that fact should be documented in a system developed with concurrency in mind. That is actually a very good example; a hash lookup is something that I would want to be able to *assume* to be read-only unless otherwise documented, because it is logically a read-only operation. If it is *not* safe to perform concurrently, I would want that documented just as much as I would want documented the fact that, e.g., read-only access to a string is unsafe. This is not meant as a complaint against SBCL. What I am saying is that in an ideal world, I would want to be able to rely on these things being either safe or documented as being unsafe. Given that Common Lisp does not deal with concurrency, there will never be a 100% guarantee with any part of the Common Lisp API. I don't know what to do about this. One would want safe use of hash table (any any other random data structure whose thread-safety with read-only operations is different on different implementations) in a thread-safe why, while at the same time not introducing locking on platforms where it is not necessary. -- / Peter Schuller, InfiDyne Technologies HB PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org _______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
