[issue30051] Document that the random module doesn't support fork

[STINNER Victor]

STINNER Victor added the comment:

Since Raymond and Antoine don't like the documentation idea, I just close my 
issue.

Hopefully, Python 3.7 now reseeds automatically random at fork!

--
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Yes, this is a feature, not a bug. But I think it is worth be explicitly 
documented.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[Antoine Pitrou]

Antoine Pitrou added the comment:

This is true, but it's by design.  If you want a specific random sequence 
(which is the primary use case for specific instances), you don't want fork() 
to mess with the random sequence.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[STINNER Victor]

STINNER Victor added the comment:

At least, it would be nice to document it for Python 3.6 and older.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Even if the global Random instance is reseeded after fork(), other instances 
are not reseeded.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[Antoine Pitrou]

Antoine Pitrou added the comment:

Victor, this issue should be obsolete now that the global Random instance is 
reseeded after fork().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[Raymond Hettinger]

Raymond Hettinger added the comment:

> os.fork() documentation contains a warning that refers to ssl
> documentation where the use of OpenSSL’s internal random number
> generator in forked processes is documented more detailed. 
> I think the same should be added for the random module.

+1 It is reasonable to extend the docs for os.fork().

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

os.fork() documentation contains a warning that refers to ssl documentation 
where the use of OpenSSL’s internal random number generator in forked processes 
is documented more detailed. I think the same should be added for the random 
module.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[Raymond Hettinger]

Raymond Hettinger added the comment:

Several thoughts:

* AFAICT, in entire the history of this module, no user has ever reported this 
as being a source of confusion, so I don't think there is a real documentation 
issue here. 

* Regarding, "after fork, the parent and the child produce the same "random" 
number sequence", this is the expected behavior of a PRNG.  If it did something 
thing different, THAT would be a bug.

* There random module is likely the wrong place for a note.   It is more 
properly a topic about forking itself.  Perhaps there is room for a FAQ entry 
about forking elaborating on the broad range of state that is shared across 
forks (lock and file descriptors, etc).

* For those who need it, the API already supports reseeding and a way to make 
new instances of Random.  Both of those are the standard ways of doing it for 
people who need independent generators in different threads.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee: docs@python -> rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I think it is worth documenting.

Even if multiprocessing reseeds the module-global random generator, it doesn't 
reseed other instances of Random.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[Antoine Pitrou]

Antoine Pitrou added the comment:

I mean mentioning fork(), which people usually don't call directly, is not 
necessary, so, indeed, a note isn't necessary.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[STINNER Victor]

STINNER Victor added the comment:

> I'm not sure that's necessary.

Do you mean that adding a note is not necessary? Or proposing a
solution in the note?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[Antoine Pitrou]

Antoine Pitrou added the comment:

I'm not sure that's necessary.  fork() is a low-level primitive, people 
can/should use multiprocessing.Process instead, which does re-seed the PRNG.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[STINNER Victor]

Changes by STINNER Victor :


--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python, rhettinger, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue30051] Document that the random module doesn't support fork

[STINNER Victor]

New submission from STINNER Victor:

When reviewing the issue #30030, it reminded me that the random module "doesn't 
support fork": after fork, the parent and the child produce the same "random" 
number sequence.

I suggest to add a quick note about that: not a warning, just a note, as a 
reminder.

There is an exception: SystemRandom produces a different sequence after fork, 
since it uses os.urandom() (which runs in the kernel).

I am tempted to propose a solution in the note like using SystemRandom, but I'm 
not sure that it's a good idea. Some users may misunderstood the note and 
always use SystemRandom where random.Random is just fine for their needs.

Proposed note:

The random module doesn't support fork: the parent and the child process will 
produce the same number sequence.

Proposed solution:

If your code uses os.fork(), a workaround is to check if os.getpid() changes 
and in that case, create a new Random instance or reseed the RNG in the child 
process.

--

The tempfile module reminds the pid and instanciates a new RNG on fork.

Another option is to not add a note, but implement the workaround directly into 
the random module. But I don't think that it's worth it. Forking is a rare 
usecase, and calling os.getpid() may slowdown the random module. (I don't 
recall if os.getpid() requires a syscall or not, I'm quite sure that it's 
optimized at least on Linux to avoid a real syscall.)

--
messages: 291534
nosy: haypo
priority: normal
severity: normal
status: open
title: Document that the random module doesn't support fork
versions: Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com