thank you very much for your enlightening remarks.
> Currently hash-tables are protected by spinlocks, so two threads can't
> be accessing the same table at the same time. This is however not a
> documented property of the public interface, and is likely to change
> in the very near future to a situation where: multiple concurrent
> readers on the same hash-table are safe, but having a writer thread +
> another concurrent thread doing either reads or writes is unsafe. Thus
> application level locks will be needed in the latter case.
Ok, I understand that. I assume the code enlarging the hash on demand will be
triggered in the same thread that intended to add an entry to the hash; so
there will be no problem there either.
> That can't happen. There will be a reference to ARR in a register of
> thread 2, which the gc will treat as a conservative pointer, and thus
> not move the array.
I see. That's great.
> There's just one gc, not individual gcs per thread.
Does the garbage collector suspend all other threads while it is working?
> You're going to lose horribly. All threads that can run Lisp code must
> have been created by sbcl, for all kinds of reasons.
Ok, so I'll have to subclass C++ classes like this one in order to make VTK or
other libraries fully functional in Lisp: