Duane Rettig  <duane@franz.com> wrote:
+---------------
| Helmut Eller <e9626484@stud3.tuwien.ac.at> writes:
| > I say it again to avoid confusion.  The example that I cited is from
| > SBCL and the code that Rob Warnock quoted is from CMUCL.  The CMUCL
| > code contains a fix for the bug (and incidentally I wrote the fix).
| > The SBCL code wasn't fixed.  
| > 
| > If you still think that the variable is lambda-bound in my example
| > then please point out where in this file:
| > http://cvs.sourceforge.net/viewcvs.py/sbcl/sbcl/src/code/reader.lisp?rev=1.42&view=auto
| 
| I did not look in any files.  The only code I _see_ earlier in this
| thread was posted by Rob Warnock.  And I was explicit in saying that
| whatever thread-safety was present there was only with respect to
| the variables themselves.  Whethere there is any other non-thread-safe
| functionality in that code must of course be considered, likely
| for example in the allocate-read-buffer code, but that is attainable.
+---------------

And my apologies for any confusion I may have inadvertently caused,
though I did include a quote containing the above URL[1] *and* the
text "This is SBCL's reader ...  And it has a threading bug", and I
did try to be clear that I was contrasting that with CMUCL by saying
"The corresponding CMUCL file contains this macro" before displaying it.

The only reason I stopped short of making a definitive statement about
SBCL having a bug was that I hadn't read *all* of the SBCL source, and
for all I knew there might have been some wrapper layer I couldn't see
that contained a fix. But Helmut says not, so no wonder I didn't see it! ;-}


-Rob

[1] Which URL I *did* go read, but failed (now understandably) to find
    thread-localizing code similar to CMUCL's.

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607