This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pocket_aces
Date 2005-06-08.22:10:56
SpamBayes Score
Marked as misclassified
Logged In: YES 

We ran across this problem when we upgraded to 2.4.  We use
python embedded in a multi-threaded C++ process and use
multiple subinterpreters.  When a subinterpreter shuts down
and the os module unloads, os._urandomfd is not closed
because it is not a file object but rather just an integer.
 As such, after a while, our process had hundreds of
dangling open file descriptors to /dev/urandom.

I would think, at the very least, if this were a file
object, it would be closed when the module was unloaded (the
deallocator for fileobject closes the file).  However, that
doesn't make it any easier for those who are forking
processes.  Probably the best bet is to close it after
reading the data.  If you need a "high performance, multiple
seek" urandom, just open /dev/urandom yourself.

Either way, this bug is not invalid and needs to be addressed.

My 2 cents..
Date User Action Args
2007-08-23 14:30:46adminlinkissue1177468 messages
2007-08-23 14:30:46admincreate