Windows uuid.uuid1 is unecessarily unsafe for concurrent use

Bug report

Bug description:

Running uuid.uuid1 concurrently in multiple parallel python processes on Windows creates colliding UUIDs, due to the timestamps colliding. Can be seen with 10-20 concurent processes usually.

This is unnecessary, as python already wraps the UuidCreateSequential() API
https://github.com/python/cpython/blob/9c1520244151f36e010c1b04bedf14747a28517d/Modules/_uuidmodule.c#L63
, but then discards the time part and falls back to some collision prone time code in https://github.com/python/cpython/blob/b4ca389281849e849fb58fecf9b31e2e2f5a39c1/Lib/uuid.py#L668 due to a claim that UuidCreate() does not follow RFC 4122.

But as far as i can tell, Windows UuidCreateSequential() does follow RFC 4122 by now, tested on Win10, so the comment looks wrong or badly aged. It is true, that the function returns the bytes in the wrong order, Little Endian, instead of the RFC prescribed Big Endian, but the rest looks sane.

This works just fine and creates a UUID thats pretty similar to the ones created by the current uuid.uuid1 implementation.

>>> import _uuid
>>> import uuid
>>> win_uuid = uuid.UUID(bytes_le=_uuid.UuidCreate())
>>> win_uuid.version
1
>>> win_uuid.variant
'specified in RFC 4122'
>>> win_uuid.time
139348915287723566
>>> win_uuid.node
185263057677337
>>> py_uuid = uuid.uuid1()
>>> py_uuid.version
1
>>> py_uuid.variant
'specified in RFC 4122'
>>> py_uuid.time
139348915744502628
>>> py_uuid.node
185263057677337

I would propose to remove the unsafe time fallback for Windows and use the results of UuidCreate() to make it safe.

CPython versions tested on:

3.11

Operating systems tested on:

Windows

Linked PRs

• gh-154737

Inizia da Lib/uuid.py intorno alla riga 668 e da Modules/_uuidmodule.c intorno alla riga 63, quindi esamina il comportamento della Windows UUID API descritto nel report. Esegui chiamate concorrenti a uuid.uuid1 su Windows e confronta i risultati con i test esistenti. Il lavoro è completato quando Windows uuid.uuid1 non produce più collisioni con il carico di lavoro di processi paralleli riportato.