commit | 31e41c4406f04f21ee7a7b31bec5567a44ff8970 | [log] [tgz] |
---|---|---|
author | Paul J. Davis <paul.joseph.davis@gmail.com> | Fri Feb 22 10:47:09 2019 -0600 |
committer | Paul J. Davis <paul.joseph.davis@gmail.com> | Fri Feb 22 10:47:09 2019 -0600 |
tree | 5f67edde197b953017bab83633d9a685d8669303 | |
parent | 2ef57339724f8bc60b8add6576e5962c4aa15df7 [diff] |
Improve handling of futures This covers two cases where a future is either immediately available and similarly when a future has already been waited on. The first case appears to be mostly when reading a key that was either previously read or set in the same transaction. The second case can happen when passing the future around. Since we've already consumed the ready message we just add a check for `is_ready`.