Message378703
| Author |
izbyshev |
| Recipients |
Yonatan Goldschmidt, gregory.p.smith, izbyshev, koobs, pablogsal, ronaldoussoren |
| Date |
2020年10月16日.05:41:48 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1602826908.83.0.360456843405.issue35823@roundup.psfhosted.org> |
| In-reply-to |
| Content |
I've updated my PR.
* After a discussion with Alexander Monakov (a GCC developer), moved vfork() into a small function to isolate it from both subprocess_fork_exec() and child_exec(). This appears to be the best strategy to avoid -Wclobbered false positives as well as potential compiler bugs.
* Got rid of VFORK_USABLE checks in function parameter lists. Now `child_sigmask` parameter is always present, but is NULL if vfork() is not available or usable. The type is `void *` to avoid hard dependence on sigset_t, which other CPython source files appear to avoid.
* Disabled vfork() in case setuid()/setgid()/setgroups() needed.
* Added more comments explaining vfork()-related stuff.
* Added commit message and NEWS entry.
Potential improvements:
* To avoid repeating long parameter lists in several functions, we can move them to a struct. The downside is that we'd need to convert child_exec() to use that struct all over the place. I don't have a strong preference here.
* Are any documentation changes needed? We don't change any interfaces, so I'm not sure.
Potential future directions:
* If desired, a vfork() opt-out may be implemented. But it'd need to disable posix_spawn() on Linux as well, since it might be implemented via vfork(), and we have no good way to check that. |
|