How to handle python subprocesses elegantly with Pyramid

Question

I've got some dummy code put together that initiates a process (exist_view) which calls a shell script and then loops through a status page that periodically checks to see if the process has produced a return code, and then render the results.

However, the results I get is that the subprocess locks rendering on the client until it's complete, which renders the 'periodic status update for the client' moot. I really need to be able to show the client that things are proceeding, as the finally project will have several consecutive subprocesses run, some of which may take minutes (this is for a custom appliance, not some website). Code snippets below. Any suggestions?

Please note that I'm working with Python 2.6.5 and 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

My illusions were dispelled in the #pyramid IRC channel.

The tl;dr is that there are 3 options:

1. Fork the process instead of using subprocess
2. Use a queue engine (like Celery)
3. Use a generator to parse results as they come in.

Here's the chat log for further elucidation:

<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.