Duane Rettig <firstname.lastname@example.org> wrote:
| Helmut Eller <email@example.com> 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 *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! ;-}
 Which URL I *did* go read, but failed (now understandably) to find
thread-localizing code similar to CMUCL's.
Rob Warnock <firstname.lastname@example.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607