Do you thought about that removed code ? https://bitbucket.org/vincentlegoll/pypy/commits/992e29624c5fd8a7e76677acf085fea0520f576d
The filedesc was not kept opened there, or do you meant another thing in this file ? On Wed, Dec 23, 2015 at 6:24 PM, Armin Rigo <ar...@tunes.org> wrote: > Hi Maciej, > > On Wed, Dec 23, 2015 at 3:48 PM, Maciej Fijalkowski <fij...@gmail.com> > wrote: >> >> I bet the difference is due to "we see more FDs in pypy". If you close the >> correct FD in CPython, it would break too I presume? Or is there special >> code to handle that? > > > There is special code to handle that in CPython. It is actually very > carefully checking that the FD is still open *and* still pointing to what it > used to. See Python/random.c. > > Just thinking aloud: what could occur here is that the forked process > reopens an unrelated file at this descriptor, and then our os.urandom() > tries to read from it---and, as a guess, the file happens to be a socket > opened in non-blocking mode, and our implementation of os.urandom() gets 0 > bytes and keeps trying to get more, which throws it into an infinite loop. > > It seems it would be a good idea to copy the careful behavior of CPython. > (There used to be another case of file descriptor kept open internally, in > rpython/rtyper/lltypesystem/llarena.py for /dev/zero, but this is gone.) > > > A bientôt, > > Armin. > > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > https://mail.python.org/mailman/listinfo/pypy-dev > -- Vincent Legoll _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
