楼上两个都说错了，这个问题产生的原因并不是多线程的问题，而是Python多线程的实现问题。
Python由于GIL的存在，并不是真正的多线程。虽然线程是系统的实线程，但线程里的代码却由一个全局的GIL控制，在以下情况下才会发生线程切换，保证所有的线程都得到解释器的执行。
IO的处理，P-code的执行行数。
所以会发生楼主的问题。由于IO阻塞，导致代码停滞，两个切换的条件都不存在，所以就把整个程序都锁死了。
解决的方法是把可能阻塞的部分用multiprocessing分开，性能可能会降低。
当然Python多线程执行的这个问题，也导致了在不手动加锁的情况下，del xx["key"]这样的操作是线程安全的，因为始终只会有一个线程访问Python的内部变量。

@ISSAY 只能用ProxyDroid模拟了

S3，相信我，HTC的做工不是一般的烂，去修一次就明白了，传说中的胶布大神，里面布满了防绝缘的胶布，而且电路设计有问题，如果进水，直接烧主板没救。另外系统上也有问题，摄像头有传说中的黑点
三棒子的东西，至少电路清晰，不用胶布来做补救，而且进水后，只要在黄金72小时内去修，一般只用换小部件。

曾经在年初的时候给年夜饭写过个类似的
https://gist.github.com/1627198
支持因为某个号码不在而取消某个号码重新抽奖。

@chaker 果然杀毒软件就是最大的病毒

@mckelvin 麻烦看清楚，pythonbrew的包隔离也是用virtualenv做的……

随便外包，几千块，做个垃圾站好了，收集网上大学的段子什么的，收入也不菲的。

@lwjefSub 能在创建env的时候，指定使用哪个Python，甚至可以指定为PyPy。具体请仔细阅读virtualenv的文档。

请求root权限的时候，是可以看到它要用root干什么的。不要随便勾选“不再提示”

干嘛要更换默认的Python版本？
这就是项目不用virtualenv的悲剧。
用virtualenv能解决你所有的问题。

分析很简单，主要的瓶颈就是在去日本的途中 219.158.33.22，从日本来的途中219.158.33.21，结合上下文，这个地方的上下站都是日本，所以应该就是出国网关的位置。
再结合BGP信息 http://bgp.he.net/ip/219.158.33.22 这个是联通的出国口。所以肯定是出口有问题。
可能是带宽不足，也可能是某墙的影响，毕竟所有的防火墙都会消耗掉很多带宽的。
不过国内的网络也确实渣，日本境内都是个位数的延迟，国内都是两位数的。

“全局的 USE flags 不要经常改，不然 emerge world 会很疼的。”
emerge可以有--new-use的

@eerie 说白了，这位楼主其实压根不会用Chrome 开发者工具和Firebug，看到Opera的一点破烂特性就高潮了。发布当天我测试了一下，Opera的DragonFly的特性只能算Chrome开发者工具的子集，Firebug的勉强子集，和IE9的差不多。

我抢了一张，用了，我GF一个全新的账号，也抢了一张，用了。
@cloudream 送货员小伙子说，货多到，他每天就早上去一趟提货点拿货，就够他送一整天了。