expand on unsoundness in the readme

Author: oconnor663

README.md

@@ -80,14 +80,19 @@ will automatically download it.
 This wrapper is not currently thread-safe. Like the hash implementations
 in the Python standard library, we release the GIL during `update`, to
 avoid blocking the entire process. However, that means that calling the
-`update` method from multiple threads at the same time is undefined
-behavior. We could solve this by putting a `Mutex` inside the wrapper
-type, but I'd like to get some expert advice about the best practice
-here first.
+`update` method on the same object from multiple threads at the same
+time is undefined behavior. We could solve this by putting a `Mutex`
+inside the wrapper type, but I'd like to get some expert advice about
+the best practice here first.
 
 A deeper problem is that another thread might mutate a `bytearray` while
 we're hashing it, and while our Rust code is treating it as a `&[u8]`.
 That violates Rust's aliasing guarantees and is also technically
 undefined behavior. However, the only possible way to solve this while
 still supporting `bytearray` would be to retain the GIL. Again, I'm in
 need of expert advice.
+
+These concerns are more theoretical than practical, however. If you're
+racing to update a hasher, or racing to hash a buffer while it's being
+written to, the result is inherently nondeterministic. That's almost
+certainly a bug in your program, whether or not it's technically sound.