The current architecture with #as makes it really hard to actually fix this. The core problem is that @index must be wrapped for thread safety.
There are a few possible arguments here:
It is possible that a small re-architecting could allow for other approaches to thread safety, by partial immutability (shared immutable source data for multiple #as-ed objects, each with their own @index). Another option which may or may not be suitable, is to use a thread local for the index.
On thread local usage, there are other things to be said, see other ticket (yet to be created).
I'm sincerely leaning towards not making this a priority until post-release (similar to async) and documenting the threading issues. What do you think?
Yes, I think that's the best approach for now, although the changes I have loosely in mind may change the semantics a little.
Alright; fiddle about in a branch, and let's see what happens... I'd really like to preserve as much of #as's semantics as possible.
For now, we are eschewing thread safety in the name of performance. Leaving this open for later though.
Closing. Re-file or re-open with (pseudo-)code demonstrating the desired feature, or a pull request, if you are so inclined.
To be frank I don't understand the use case: make Result objects concurrently fetchable from multiple threads? If so, why? If so, by default? Etc. Most database abstractions don't help the underlying bindings be more thread-safe than they are, and very few are. (Python's DB API 2 outlines stepped gradations of threadsafety, and very few — any? — of the common drivers achieve "shared cursors," which is what I think this ticket is asking for.)