Result lacks thread safety #3

raggi opened this Issue Jul 9, 2010 · 5 comments

3 participants

RDBI member

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:

  • Results should not need to be thread safe - they should be used by one thread only (sane).
  • #as should dup results such that each has it's own @index and result data.

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?

RDBI member

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.

@pilcrow pilcrow was assigned Mar 17, 2013
RDBI member

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.)

@pilcrow pilcrow closed this Mar 17, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment