From: ra To: tor-dev@lists.torproject.org Date: Sat, 10 Aug 2013 01:33:24 +0200 References: <201307270253.43066.r_a@lavabit.com> <201307290116.13929.r_a@lavabit.com> In-Reply-To: MIME-Version: 1.0 Message-Id: <201308100133.30028.r.a@posteo.net> Subject: Re: [tor-dev] Status report - Stream-RTT X-BeenThere: tor-dev@lists.torproject.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tor-dev@lists.torproject.org List-Id: discussion regarding Tor development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5958998101793692453==" Errors-To: tor-dev-bounces@lists.torproject.org --===============5958998101793692453== Content-Type: multipart/signed; boundary="nextPart1404475.tnyOK3Ka33"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart1404475.tnyOK3Ka33 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Monday 05 August 2013 07:25:20 Damian Johnson wrote: > Yup. It's unfortunate that tor decided to include an 'Exit' flag with > such an unintuitive meaning. You're not the first person to be > confused by it. Is this meaning at least documented somewhere and I have just read over it? > > -) It is not safe to use extend_circuit in parallel for creating new > > circuits. I think this is not mentioned anywhere. >=20 > What kind of issue does that encounter? Is it a problem with stem's > thread safety or an issue on tor's side? If requests are sent to Tor to create more then a single circuit at once, t= he=20 mapping between circuit events and create-request is unknown because the=20 circuit ID is not known until the LAUNCHED-event has been received. This is clearly an issue on Tor's side but one could argue that Stem should= =20 stop me from using it that way. > Manual lock handling is risky. If anything within this block raises an > exception (and there's several points throughout your script where you > use Controller methods that can potentially raise errors) then the > lock won't be released. >=20 > The safer way of doing this is to use the 'with' keyword... I could get rid of all manual locking besides in one case. > Not necessary. Methods return None by default. Removed. > You might want to look into pyflakes and pep8. I've found them to be > better static analysis tools. pyflakes didn't say anything but I commited lots of cosmetic pep8 changes . > > try: > > controller =3D connect_port() > >=20 > > except SocketError: > > sys.stderr.write("ERROR: Couldn't connect to Tor.\n") > > sys.exit(1) > >=20 > > controller.authenticate() >=20 > Not quite. The connect_port() function never returns an exception. > Rather, if it fails to establish a control connection then it prints > the issue to stdout and returns None. Also, the connection it provides > is already authenticated. If Tor has ControlPort enabled without having HashedControlPassword set,=20 authenticate() has to be called to authenticate the connection. Though this is not recommended I don't know which other default setting wou= ld=20 be more appropriate. > This should instead be... >=20 > controller =3D connect_port() >=20 > if not controller: > sys.exit(1) # failed to get a control connenction =46ixed. Best, Robert --nextPart1404475.tnyOK3Ka33 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEABECAAYFAlIFfEkACgkQ9eiEAFCVEWTajwCgwh7q2XAPD/+PPNLoPf6t56zg uocAnAzC+gx7MD1qzFo08FnlRurl+b2V =Ryjr -----END PGP SIGNATURE----- --nextPart1404475.tnyOK3Ka33-- --===============5958998101793692453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev --===============5958998101793692453==--