On 18/11/16 15:19, James K. Lowden wrote: > Good catch, Roger. It's a liability, but I slightly disagree with your > characterization. > >> - Running any Python code (destructors can be called which then run in >> the parent and child) > > Yes, if those destructors affect shared resources. The OP did say the > processes on the other side of popen were C programs.
You missed a subtlety. The fork call is made from Python code. The parent and child keep running Python code. Eventually the child calls exec and similar. In the child process between the fork call return and the exec call, the Python code that runs can include the destructors for Python wrapped SQLite objects. >> - Not having file descriptors closed so the child process trashes them >> (close_fds Popen argument is False in python 2.x but True in python >> 3.x). > > The child process can't "trash" the parent's descriptors. Lets say the SQLite database is on fd 3 in the parent process. That makes it fd 3 in the child process too after the fork. And if not closed, it will be fd 3 in whatever gets execed. This scenario is the very first one listed in how to corrupt: https://www.sqlite.org/howtocorrupt.html >> Also python 2.x subprocess module is broken in many ways. > > My foray into Unicode in Python convinced me once and for all that > Python 3 is the only way to go. But would you care to elaborate on the > problems with 2.x subprocess? The Python 2.x subprocess module is implemented in Python. It has race conditions and other problems when the parent is multi-threaded. They aren't theoretical, and affected the project I work on. When debugging you find yourself in "impossible" situations. My memory is a bit fuzzy now, but it was things like file descriptors between parent and child not being as expected. Python 3 includes a pure C implementation of code that runs from fork through exec. Someone at Google backported that to 2.x, so they must have been affected too. https://github.com/google/python-subprocess32 Roger
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
