Armadilloフォーラム

佐藤さん、

マルティネです。

> Armadillo Base OSとpythonでどう開発してよいかがわかっていない部分もあります。
> ゆくゆくはwebサーバを立ててPCと接続するような形にしたいと思っています。
> RS485で下位装置からデータをポーリングしてその結果を表示するので
> 通常表示するデータはファイルで共有し
> PCからの設定書き込みはRS485のコンテナに送信して行うようになるのかなと。

なるほど、RS485 の処理でプロセスがブロッキングされているので、別のプロセスでPCからの設定などを対応するということですね。

> CUIアプリケーションでデバッグしながら開発する上で
> それぞれの機能でコンテナが分かれていた方がよいのかと考えました。
>
> それともpython_app.confに
> set_command python3 ***.py
> を追加するなどできるのでしょうか？

set_command は一つしか設定できません、最後の set_command だけの残ります。
コマンドを run.sh に変更して run.sh で python3 a.py & python3 b.py の様に設定すれば、いくつかのプログラムを起動できますが、プロセスの管理機能を失います：デフォルトでは、実行するコマンドが失敗する場合にコンテナがリスタートされますが、a.py のステータスはまったく管理から外れていますし、b.py が停止されたら a.py も強制的に停止されます。

その面では、二つの python コマンドを実行したい場合はプロジェクトを二つ作る判断が正しいと思います…が、二つの python プロセスではなく、 threading か multiprocess で管理した方がプロセス同士の通信が楽なきがします。

> そちらの方が効率よいですか？

そうですね、効率としてはコンテナも結局普通のプロセスとして管理されているので、そんなに違いはありません
- ランタイムでは、起動が少し遅くなりますが、起動されたら CPU 負担が同じです。メモリの面では管理プロセスや cgroup が増えますので 1-2MB 程度のメモリが諸費されますが、python に比べたら小さい差だと思います。
- ディスクの方は単純に別のプロジェクトを使うとコンテナイメージが二重されますので、各python_app.conf で同じイメージを使うようにしないと無駄がでますね。（python_app.conf のファイル名を変えないとどれかしか起動でいないと思いますが、そこはうまく変更できましたか？）

一方、multiprocess か threading を使うと：
- 「アプリケーション」としては一個しかないので、管理するプログラムも一つでいいはずです
- python のビルトインなので、通信方法もスタンダードにできます。
- threading と queue を使って、協力するスレッドの例は https://qiita.com/virusyun/items/f3716e4ec42b6b9cd67b でわかりやすく説明されていると思いました。

なので、色々説明した後ですみませんが、一度 threading をみていただけたらいいかもしれません。

よろしくお願いします。