Not threadsafe

[sean-public]

Not threadsafe

[sean-public]

As the README indicates, it currently offers "fine-grained locking on insert and delete combined with optimistic search" which is why, for example, getPrevElementNodes does not acquire a lock.

A new version is being tested with streamlined across-the-board optimistic locking via revision number incremented on writes and optionally supplied with write requests -- returning an error when the versions don't match that can be acted upon in the client (à la Elasticsearch). I apologize for the delay in getting the new version on Github, it's part of a larger ongoing project in a private repo.

I'll update this issue when it's merged in to be sure you're notified.

[jaffee]

Hey @sean-public thanks for getting back to me - I don't actually need thread safety for my use, so I'm just stripping out all locking in a fork, but I do want to point this out because I think it's very important. I'd also like to say, that concurrency issues aside, I really like this library - it's a nice implementation with lots of benchmarks and the code is tiny!

Instead of trying to explain in this issue, I've simply made a pull request with a test which shows one of the possible data races happening: #4

This article: https://golang.org/doc/articles/race_detector.html has more information on what precisely constitutes a data race, and why even "innocent" races on primitive types can lead to problems.

[0joshuaolson1]

Why was this issue closed? SetMaxLevel isn't documented as thread-unsafe.