> > How hard would it be to reimplement our own system() and popen() using > > only POSIX calls, for POSIX systems? I've always thought of these to > > be pretty simple combinations of fork() and exec(), with an assumption > > of a working /bin/sh. > > I would be concerned that we bypass magic that the system vendor put > into system(), which is essential for proper operation. For example, > on Linux, system() blocks SIGINT in the parent process while the > child is running. Also, the shell executable that system() uses > may not be /bin/sh. In practice, I think we can do as well as vendors -- there really isn't that much to it. Systems where /bin/sh doesn't exist will have other problems... And we get to do it right when called from a thread. > OTOH, using the same underlying implementation on all systems makes > Python behave more predictable. > > In the specific case, we would not even need pthread_atfork anymore, > as we now could invoke PyOS_AfterFork in the child ourselves. Right! --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4