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 が衝突を生成しなくなることです。