Safe UUID - is not safe.

[cfrademan]

Bug report

Bug description:

The following works as expected.

import uuid
import multiprocessing

def worker(_):
    # Happy days.. she is unique...
    print(uuid.uuid1())

with multiprocessing.Pool(4) as p:
    r = p.imap_unordered(worker, list(range(4)))
    for x in r:
        _ = x

output:

chris@bounce:~/code$ python3 working.py
1f791abc-026b-11ef-aeb4-d3e6c19eeb6e
1f791de6-026b-11ef-aeb5-d3e6c19eeb6e
1f792836-026b-11ef-aeb5-d3e6c19eeb6e
1f792912-026b-11ef-aeb6-d3e6c19eeb6e
chris@bounce:~/code$

However, just 1 line, by issuing a unique uuid1 before the forking process, breaks it...

import uuid
import multiprocessing

# NOTE(cfrademan): Chaos. (such is life)
break_it = uuid.uuid1()

def worker(_):
    # She is not unique :-(
    print(uuid.uuid1())

with multiprocessing.Pool(4) as p:
    r = p.imap_unordered(worker, list(range(4)))
    for x in r:
        _ = x

output:

chris@bounce:~/code$ python3 broken.py
352a17db-026b-11ef-aeb6-d3e6c19eeb6e
352a17db-026b-11ef-aeb6-d3e6c19eeb6e
352a17db-026b-11ef-aeb6-d3e6c19eeb6e
352a17db-026b-11ef-aeb6-d3e6c19eeb6e

It seems like a global state being passed over to a forked process from the C side.

Our workaround is to ensure we don't hit this. We run os.getpid() on every call on our UUID wrapper to raise a RunTimeError if one of our devs decides to use our wrapper before any processes are forked. Luckily, we had this wrapper to check that the UUID was safely generated.

If this is expected behaviour, it should be documented for whatever reason.

My recommendation is that UUID should have a keyword argument to raise if not safely generated. Now we have a wrapper that has to do two more things than it should.

No rush, but if I have any time available, I would help on this.

Many thanks!

CPython versions tested on:

3.10

Operating systems tested on:

Linux

[colesbury]

This looks like a duplicate of the issue you linked to #105337