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

先从 Lib/uuid.py 第 668 行附近和 Modules/_uuidmodule.c 第 63 行附近开始，然后检查报告中描述的 Windows UUID API 行为。在 Windows 上并发运行 uuid.uuid1 调用，并将结果与现有测试进行比较。完成的标准是，在报告所述的并行进程工作负载下，Windows uuid.uuid1 不再产生冲突。