I think I've fixed this bug. I took dan`b's advice and locally bound
*read-buffer*, *ouch-ptr* and *inch-ptr* during thread creation in
make-thread. I've attached the diff.
I've run my test case and got no read errors where I used to get 2-3
during the run so I think it's fixed the problem.
I have still been getting one other error though:
mmap: Cannot allocate memory
unhandled condition (of type SB-INT:SIMPLE-CONTROL-ERROR):
attempt to RETURN-FROM a block or GO to a tag that no longer exists
Is this just SBCL running out of memory or is it possibly to do with
thread contention for memory addresses?
On Mon, 2004-04-19 at 23:11, Christophe Rhodes wrote:
> Robert Marlow <bobstopper@...> writes:
> > 10: (SB-IMPL::MAKE-INTEGER 0)[:EXTERNAL]
> This is where the error is occurring... and I suspect I know what's
> going on.
> The tokeniser uses global buffers to do its tokenization (have a look
> at the use of *read-buffer* in src/code/reader.lisp). This means that
> if two threads attempt to tokenise at once, something much like what
> you've observed will happen, for instance when DIGIT-CHAR-P (in
> MAKE-INTEGER) gets called on a non-numeric character.
> I don't have a ready fix right now. The quick fix, but with possible
> performance implications, is to bind *read-buffer* to a fresh array
> somewhere in src/code/reader.lisp (and *read-buffer-length*, too). If
> that turns out to be too consy, then maybe a pool of buffers needs to
> be implemented.