Allow dominate to work in async contexts

[tlonny]

Hi everyone,

This PR uses Context vars to help distinguish between different async contexts. This prevents two concurrent document edits running in an event loop from bleeding into each other.

With this fix, I hope dominate can be safely used with async web frameworks like sanic etc.

[apalala]

My apologies for jumping in here!

The proposed changes seem reasonable and simple enough.

Perhaps itertools.count() could be used for the counter? Yet my preference for unique identifiers is to use uuid.uuid1().

Also it would be good to take the opportunity to use something with less chances of collisions than hash().

https://stackoverflow.com/questions/47601592/safest-way-to-generate-a-unique-hash-in-python

[tlonny]

Hi @apalala - thanks for your reply!

Although I can't imagine a situation where we get an accidental collision with async_context_id_counter, I agree it can't hurt to eliminate the risk entirely by using an UUID instead. Can I ask why uuid1 vs uuid4?

My understanding was that a region of the uuid1 is taken up by the computer's MAC address (or a similar, static identifier) - for the purposes of avoiding collisions, this region will always be the same and thus is "wasted space" that could otherwise be used to produce more randomness and push the collision risk lower.

With respect to your last point on hash() - why do we even need hash in the first place? Can't we just pass the tuple as-is into the dictionary?

[apalala]

HI @tlonny!

Any UUID is good because it will resolve race conditions in both async and threading.

Using hash() is not satisfactory. Python's hash() is allowed to produce collisions because it's intention is to produce fair hashing (dict, set, etc.) and not uniqueness.

Using the tuple is correct, but using a sha1 or sha3 is more efficient in comparisons.

My own preference would be to use the tuple because it's correct, it's good enough, and it makes any upcoming debugging easier.

[tlonny]

Great,

So action items for me:

• implement unique async ids using UUIDs
• return the raw tuple vs. its hash.

I'll get these added to the PR v. soon

Thanks for the feedback mate!

[tlonny]

@apalala - Changes implemented :-)

[coveralls]

coverage: 100.0%. remained the same
when pulling 5746232 on tlonny:master
into 4a66756 on Knio:master.

[tlonny]

@Knio - are we good to merge this bad boy? Happy Xmas BTW