Hannu Koivisto <azure@...> writes:
> Test setup: SBCL 0.9.6.8 from CVS as of 20051029T1239Z, built with
> :sb-futex, :sb-thread but without :sb-unicode, running on Debian
> GNU/Linux x86, kernel 2.6.8 SMP, the machine is 2.8GHz P4 with
> hyperthreading enabled. It may be possible that this cannot be
> (as) easily reproduced on a slow machine.
I cannot reproduce this with recent (0.9.15 series SBCL), at least
not on an uniprocessor machine.
Does this still happen for you with current CVS?
> writes data mimics the bivalent streams code in acl-compat. And
> the reason why I did that is that I see the corruption when using
> portableaserve client code to do requests from multiple threads at
...however, I it came to my attention yesterday, that
1. Portableaserve is not ATM thread-safe in SBCL: it relies on
WITHOUT-SCHEDULING, whose implementation in ACL-COMPAT for
SBCL is just a NOP.
2. STABLE-SORT and ADJUST-ARRAY are not thread-safe in SBCL.
(Will fix soon.)
> WITH-PINNED-OBJECTS is not necessary for such objects. But it
> seems to me that those buffers are bypassed when FROB-OUTPUT is
> called from the last branch of COND in OUTPUT-RAW-BYTES.
At a glance it seems to me that you are quite right, and the call
should be protected with WITHOUT-GCING.
-- Nikodemus Schemer: "Buddha is small, clean, and serious."
Lispnik: "Buddha is big, has hairy armpits, and laughs."