Traceback (most recent call last):
File "./demo.py", line 109, in <module>
if __name__ == "__main__": web.run(urls, globals(), web.reloader)
File "/home/huahua/work/se/web/request.py", line 145, in run
return wsgi.runwsgi(webapi.wsgifunc(webpyfunc(inp, fvars,
autoreload), *middleware))
File "/home/huahua/work/se/web/wsgi.py", line 54, in runwsgi
return httpserver.runsimple(func, validip(listget(sys.argv, 1,
'')))
File "/home/huahua/work/se/web/httpserver.py", line 221, in
runsimple
server.start()
File "/home/huahua/work/se/web/wsgiserver/__init__.py", line 869, in
start
self.tick()
File "/home/huahua/work/se/web/wsgiserver/__init__.py", line 896, in
tick
s, addr = self.socket.accept()
File "/usr/lib/python2.5/socket.py", line 167, in accept
sock, addr = self._sock.accept()
socket.error: (4, 'Interrupted system call')
<学费> 什么时候发生?
<学费> 随机?
<学费> linux 后来说解决了一个事件唤醒所有进程的问题, 那么后来一次connect唤醒一个select中的进程, 如果他不accept
光屁股跑回来继续select的话 那个connect会如何?
<学费> Westwind 同学回答
<左手> baa, 貌似随机的
<左手> baa, 最近一天当一次
<学费> 连接频繁么?
<学费> 你要reproduce的话可以每秒kill -HUP一次他
<学费> 解决办法是用try把那个错误给catch下来
<学费> 而且仅catch那个错误
<学费> 如果他是同一个类型(class) 只是错误代码不一样, 那你catch了再if判断一下 符合的就retry 不符合的就继续
throw
<学费> php在这方面也做的不好, 他们以为c级别如此, 更高层也该如此行为
<左手> baa, ab 她的时候貌似怎么都弄不掉, 走开了就不知道啥时候会当掉
<学费> 实际上他有独立的 signal 处理机制, 完全可以把这个错误给封装起来
<学费> 你ab + while true; kill ...
<学费> 不过走开之后是远程connect导致的?
<学费> 本地重演也许不容易
<学费> 主要是accept系统调用的时候 还没返回 就signal
<学费> 实在不好重现的话就直接改代码看效果吧
<学费> 不看广告看疗效
<左手> 这个机器在内网,connect 不频繁
<左手> 当的时候可能没 connect
<左手> ab -c 100 -n 1000 的 http://paste.ubuntu.org.cn/2486
<学费> 原来这个玉米在你的魔爪之下...
<学费> 这个界面的语言是自动的么?
<学费> 还是单一的?
<左手> 单一的
<学费> ......
<左手> baa, 似乎是没 connect 的时候自己当掉
<学费> 嗯
<学费> 那就是你的程序没事就accept在那里卡住了
<学费> 然后alarm信号把他给唤醒了
<学费> 我也不知道什么时候会如此
<左手> err, 学费能把你的分析贴 ml 上么 ?
<学费> 我有一大半是瞎猜的
<学费> 没实际这么干过
看起来是web.py的bug,它没有处理在执行accept()时插进来的系统中断。可以参考其他python的web应用改一下,比如trac的处理方式,忽略掉就可以了:
http://tinyurl.com/3by5xm