我有一些虚拟代码放在一起启动一个进程（exist_view），它调用一个shell脚本，然后遍历一个状态页面，定期检查进程是否产生了返回代码，然后呈现结果
然而，我得到的结果是子进程锁定客户端上的呈现直到它完成，这使得“客户端的定期状态更新”没有实际意义。我真的需要能够向客户端显示事情正在进行，因为最终项目将运行几个连续的子流程，其中一些可能需要几分钟（这是针对自定义设备，而不是某些网站）。代码片段如下。有什么建议吗？
请注意，我正在使用Python 2.6.5和Pyramid 1.4。
@view_config(route_name='waiting', renderer='waiting.mako')
def waiting_view(request, process):
while process.poll() == None:
time.sleep(1)
print str(process.returncode)
return {}
@view_config(route_name='exist', renderer='exist.mako')
def exist_view(request):
process = subprocess.Popen(['bash', '-c', './dummy.sh'], stdout=subprocess.PIPE)
return HTTPFound(request.route_url('waiting', process=process))
答案 0 :(得分：2)
我的幻想在#pyramid IRC频道被驱散。
tl; dr是有3个选项：
以下是进一步说明的聊天记录：
<phira> hewhocutsdown: that's never going to work
<phira> hewhocutsdown: I can see what you're trying to do, but the threading/request system doesn't work like that
* chrisrossi has quit (Ping timeout: 264 seconds)
<hewhocutsdown> hrm... is there another approach I could take, or is that strictly precluded?
<phira> hewhocutsdown: what you want is most likely to use one of the queue engines like celery or gearman to run the process from a pool
<phira> that approach is probably the most normal production approach to take
<phira> if you're after a simpler, quicker hack you have two options. The first is to fork the whole process and have it write to a file or something, that waiting_view can read from to get status
<phira> the second is to use a generator as the return on exist_view and let it feed out the results of the process bit by bit as they arrive, effectively turning it into a long poll
<hewhocutsdown> yeah, I looked at Celery but I don't have enough server control to be able to load it. // the forking idea could be done // what do you mean by a generator?
<hewhocutsdown> and to clarify; the .sh is basically copying and configuring Xen images
<hewhocutsdown> so they're simple scripts but they may take a while to respond
<pdobrogost> graffic: it doesn't need to be stable to be used in trasactions. what you see (or you image you see) is irrelevant here
<phira> ok, in that case I'd go with the forking thing
<phira> the one problem you're gonna have is that you can lose track of the processes (ie you fork one, and forget its there and it zombies or similar), you can deal with this in a variety of ways using process pools but they're not really a pyramid issue
<phira> the key point to remember is that you can't set a variable in one view, and have another view do things with it. Your views are (often) in separate thread contexts and unless you play a very careful game of thread safety they can't talk to each other like that, any info they want to share needs to go through the database or filesystem.
<hewhocutsdown> yeah, I don't have a db, at present it's just filesystem (calling shell scripts/reading return codes/writing text files). I'll take a stab at prototyping the fork method. Just so I know, how would the generator method work?
<phira> with the generator you return aresponse that basically returns the lines as they arrive from the script or similar, slowly (so the request takes ages, basically, but starts feeding out information almost immediately). You can then use xhr on the client side to call that url (once) to start the process and read the results as they happen
<phira> the risk of doing so is that you have no way of restarting it. If the client loses the connection, they cannot re-poll the endpoint because that will start a new process, instead of talk to the old one
<hewhocutsdown> got it. yes, I did something similar before I switched to using return codes.
<phira> there are strategies to get around that, but it's rarely worth the effort.
<hewhocutsdown> alright, I'll look into forking and process pooling.
<hewhocutsdown> thank you
<phira> no problem
<phira> also for what it's worth, this is probably the right place for almost any pyramid related question, the people here know all the things and they're usually around. THat's not always the case for some channels so I figure it's worth saying.