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 | gregory.p.smith |
|---|---|
| Recipients | Rhamphoryncus, amaury.forgeotdarc, gregory.p.smith, jnoller, mikemccand, pitrou, tzot |
| Date | 2008年07月13日.06:18:01 |
| SpamBayes Score | 0.004858303 |
| Marked as misclassified | No |
| Message-id | <1215929885.35.0.765921085818.issue874900@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
I still don't like the _after_fork() implementation. Its O(n) where n == number of threads the parent process had. Very wasteful when the fork() was done in the most common case of being followed by an exec and calling os._exit(). It won't scale nicely with system load (forks will start taking longer and longer the more threads exist). Could os.fork() be extended to have an optional will_exec_or_die parameter that determines if _after_fork() is even called at all? Things like subprocess should pass in True. The default should be False for compatiblity. |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年07月13日 06:18:05 | gregory.p.smith | set | spambayes_score: 0.0048583 -> 0.004858303 recipients: + gregory.p.smith, mikemccand, tzot, amaury.forgeotdarc, Rhamphoryncus, pitrou, jnoller |
| 2008年07月13日 06:18:05 | gregory.p.smith | set | spambayes_score: 0.0048583 -> 0.0048583 messageid: <1215929885.35.0.765921085818.issue874900@psf.upfronthosting.co.za> |
| 2008年07月13日 06:18:03 | gregory.p.smith | link | issue874900 messages |
| 2008年07月13日 06:18:02 | gregory.p.smith | create | |