Message151423
| Author |
ferringb |
| Recipients |
amaury.forgeotdarc, ferringb, gregory.p.smith, milko.krachounov, pitrou, zhigang |
| Date |
2012年01月17日.02:17:06 |
| SpamBayes Score |
9.798313e-06 |
| Marked as misclassified |
No |
| Message-id |
<1326766627.8.0.791474824618.issue6559@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Just noticed this patch... aside from liking the intention, the api for this is going to grow tiresome quick since it expects the FDs to already be in place; is there any reasons a mapping wasn't used here, specifically of (src_fd|src_fileobj) -> target_fd ?
If that was fed in, post fork the client can shuffle around the fd's into appropriate positions- something the parent may not be able to do (threaded environment for example, or async in some respect).
I've had similar functionality in my own process code for a while, and have found it to be generally pretty easy to deal with- for subprocess it has the added benefit that the existing stdin/stdout/stderr bits could be pretty easily folded directly into it.
So... any reason this route wasn't considered, or just wasn't thought about? |
|