如何用金字塔优雅地处理python子进程

Question

我有一些虚拟代码放在一起，启动一个进程（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)) 

Answer 1

我的幻想消失在#pyramid IRC频道。

对TL; dr为有3个选项：

1. 叉的过程，而不是使用子
2. 使用队列引擎（如芹菜）
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.