From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.50) id 1EVuMF-0002UH-LH for garchives@archives.gentoo.org; Sat, 29 Oct 2005 17:19:08 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.5/8.13.5) with SMTP id j9THIM3t022477; Sat, 29 Oct 2005 17:18:22 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [134.68.220.30]) by robin.gentoo.org (8.13.5/8.13.5) with ESMTP id j9THILYT030412 for ; Sat, 29 Oct 2005 17:18:21 GMT Received: from cpe-65-26-255-237.wi.res.rr.com ([65.26.255.237] helo=nightcrawler) by smtp.gentoo.org with esmtpa (Exim 4.43) id 1EVuLV-0002z6-2f for gentoo-portage-dev@lists.gentoo.org; Sat, 29 Oct 2005 17:18:21 +0000 Date: Sat, 29 Oct 2005 12:17:53 -0500 From: Brian Harring To: gentoo-portage-dev@lists.gentoo.org Subject: Re: [gentoo-portage-dev] [5/7] portage_exec cleanups Message-ID: <20051029171753.GP24883@nightcrawler> References: <200510231545.16596.jstubbs@gentoo.org> <200510300025.23180.jstubbs@gentoo.org> <20051029160410.GO24883@nightcrawler> <200510300140.41639.jstubbs@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gV1yUYniiDLxW66s" Content-Disposition: inline In-Reply-To: <200510300140.41639.jstubbs@gentoo.org> User-Agent: Mutt/1.5.8i X-Archives-Salt: bf92b18f-d970-4504-a97b-ecdb17f037ca X-Archives-Hash: 9c6e8cb9a8d3f4790be920d2108093f6 --gV1yUYniiDLxW66s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 30, 2005 at 01:40:41AM +0900, Jason Stubbs wrote: > Even with the fd_pipes, the try/except block in there covers a bug that i= s hit=20 > every time it is entered. *cough* really doesn't surprise me. :) > > Looking through the 2.4 subprocess module (which came along after the > > mods in question), adding an option controlling the fd cleansing would > > make sense, as long as the default option is to close the fds. >=20 > Given the threading comment, I'd be agreeable to this. However, the spawn= of=20 > tee would have to specifically close the write side of the pipe when unkn= own=20 > FDs aren't closed. Is having two extra paramaters, close_fds (a list) and= =20 > close_all_fds (a bool), to spawn okay? It's needed for any logged calls, doesn't mean I like it though. How=20 about this,=20 def spawn(...close_fds=3DTrue...): if close_fds is True: # kill all that aren't marked for open elif close_fds: # must be an iterable of what to kill else: #whatever code required to keep it from nuking file handles Don't really like that one much myself, but it would allow for the=20 logging to use the existing structure, and one less option on the=20 overgrown spawn* prototype(s).=20 sidenote, since max_fd_limit needs to survive, tag=20 try: import resource - max_fd_limit=3Dresource.getrlimit(RLIMIT_NOFILE) + max_fd_limit=3Dresource.getrlimit(resource.RLIMIT_NOFILE) except SystemExit, e: raise in while you're at it, since that's obviously broke. Current code=20 would default to range(256), but default is 1024 fds for gentoo boxes=20 (so that _is_ a hole). ~harring --gV1yUYniiDLxW66s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDY67BvdBxRoA3VU0RAp66AKCRVDV8E4uuZXMJ+HfjwGBfB4U2NACfanRd knlfVp9AeIZOs26gG+e8KBM= =82EM -----END PGP SIGNATURE----- --gV1yUYniiDLxW66s-- -- gentoo-portage-dev@gentoo.org mailing list