1

シェル スクリプトを呼び出すプロセス (exist_view) を開始し、プロセスがリターン コードを生成したかどうかを定期的にチェックして結果を表示するステータス ページをループするダミー コードをまとめました。

しかし、私が得た結果は、サブプロセスが完了するまでクライアントでのレンダリングをロックし、「クライアントの定期的なステータス更新」を無意味にレンダリングすることです。最終的なプロジェクトではいくつかの連続したサブプロセスが実行され、そのうちのいくつかは数分かかる場合があるため、物事が進行していることをクライアントに示すことができるようにする必要があります (これはカスタム アプライアンス用であり、一部の Web サイトではありません)。以下のコード スニペット。助言がありますか？

私は 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))
4

1 に答える 1

2

私の幻想は #pyramid IRC チャンネルで解消されました。

tl;dr は、3 つのオプションがあることです。

  1. サブプロセスを使用する代わりにプロセスをフォークする
  2. キュー エンジンを使用する (Celery など)
  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.
于 2013-04-24T14:36:33.697 に答える