電装工芸日記
- 舞台照明機器の製作とか -
2023年7月21日の投稿［2件］
Python をスレッドに分ける基準についてオレメモです。
待ち時間が発生する処理単位をスレッドとして独立化することが基本的な考え方でしょう。デバイスの応答待ちや重い処理の終了待ちがある場合です。この間に何もしなくていいならスレッド化をする必要はありませんが、大概は待ち時間に他の処理を平行して行うことになるからです。
この様な想定がされる場合は最初からマルチスレッドで書き始めるのが良さそうです。主処理を親スレッドとしてサブルーチン的な子スレッドを定義する手もありますが、親スレッドはスレッド間通信の管理と子スレッドの起動・終了だけを扱うようにするとわかりやすいような気がします。
スレッド間通信の手段はデータ量や求める速度によりますが Queue を使うのが良さそうです。Tuple で包めばどんな型でもやりとり出来ますし、FIFO スタックなのでスレッド間のタイミング管理が楽です。
こういった検討する場合、一つのプロセスで処理しきれるかも同時に検討します。OS次第ではありますが、一つのプロセスは一つのCPUスレッドで処理されるのが普通ですから、処理が重い場合はプロセスを分けてCPUスレッドを分散させた方がいいこともあります。ただし、プロセスを分けると子プロセスを起動するのに時間がかかり、プロセス間通信も手続きが煩雑ですので、ハードウェアの能力を余すところなく使えそうなマルチプロセスが必ずしも最良の選択とは言えません。
#Python
待ち時間が発生する処理単位をスレッドとして独立化することが基本的な考え方でしょう。デバイスの応答待ちや重い処理の終了待ちがある場合です。この間に何もしなくていいならスレッド化をする必要はありませんが、大概は待ち時間に他の処理を平行して行うことになるからです。
この様な想定がされる場合は最初からマルチスレッドで書き始めるのが良さそうです。主処理を親スレッドとしてサブルーチン的な子スレッドを定義する手もありますが、親スレッドはスレッド間通信の管理と子スレッドの起動・終了だけを扱うようにするとわかりやすいような気がします。
スレッド間通信の手段はデータ量や求める速度によりますが Queue を使うのが良さそうです。Tuple で包めばどんな型でもやりとり出来ますし、FIFO スタックなのでスレッド間のタイミング管理が楽です。
こういった検討する場合、一つのプロセスで処理しきれるかも同時に検討します。OS次第ではありますが、一つのプロセスは一つのCPUスレッドで処理されるのが普通ですから、処理が重い場合はプロセスを分けてCPUスレッドを分散させた方がいいこともあります。ただし、プロセスを分けると子プロセスを起動するのに時間がかかり、プロセス間通信も手続きが煩雑ですので、ハードウェアの能力を余すところなく使えそうなマルチプロセスが必ずしも最良の選択とは言えません。
#Python
コロナも明けた感じで繁忙期に入っています。開発・製作をする時間が取りにくくなってきました。
LTC Player は早く欲しい気持ちはあるものの、近日中に使いたい案件があるワケではありません。１年くらいかけてノンビリ作るつもりです。
先日も書きましたが、Python らしい様式で書き直そうと思います。マルチスレッドの基本構造を最初から組み入れ、平文ではなく構造化・ライブラリ化(ヘッダーファイル化)を進め、可能な部分は出来るだけクラス化するのです。
PysimpleGUIも読みやすく手直しがしやすい書き方を検討したいですね。ウェジット一つにも設定項目が多いのでちょっとしたウィンドウ作るだけで膨大なコマンド数になりますが、これを出来るだけ簡素に書きたいのです。他人に読んでもらう気はありませんが、２年後の自分が理解できるようには書きたいかなと。PysimpleGUIは他の製作でも使いたいので、習作というか自分なりのひな形作りも兼ねるつもりです。
複数のファイルを使って構造的に書いていきますので VSCode を使った方が楽です。RaspberryPi の開発では便利に使っていますが、目的・用途に合わせたセッティングの仕方をオレマニュアルにまとめる必要があります。VSCode は素直で使いやすいエディタだと思うのですが、やれることが多すぎるので最初の段取りをキチンと踏まないと後で困るからです。
ファイル１枚の短いモノなら秀丸エディタでチョイチョイ書いた方が手っ取り早いのですけど、LTC PLayer はそういう規模ではなくなっています。
#Python
LTC Player は早く欲しい気持ちはあるものの、近日中に使いたい案件があるワケではありません。１年くらいかけてノンビリ作るつもりです。
先日も書きましたが、Python らしい様式で書き直そうと思います。マルチスレッドの基本構造を最初から組み入れ、平文ではなく構造化・ライブラリ化(ヘッダーファイル化)を進め、可能な部分は出来るだけクラス化するのです。
PysimpleGUIも読みやすく手直しがしやすい書き方を検討したいですね。ウェジット一つにも設定項目が多いのでちょっとしたウィンドウ作るだけで膨大なコマンド数になりますが、これを出来るだけ簡素に書きたいのです。他人に読んでもらう気はありませんが、２年後の自分が理解できるようには書きたいかなと。PysimpleGUIは他の製作でも使いたいので、習作というか自分なりのひな形作りも兼ねるつもりです。
複数のファイルを使って構造的に書いていきますので VSCode を使った方が楽です。RaspberryPi の開発では便利に使っていますが、目的・用途に合わせたセッティングの仕方をオレマニュアルにまとめる必要があります。VSCode は素直で使いやすいエディタだと思うのですが、やれることが多すぎるので最初の段取りをキチンと踏まないと後で困るからです。
ファイル１枚の短いモノなら秀丸エディタでチョイチョイ書いた方が手っ取り早いのですけど、LTC PLayer はそういう規模ではなくなっています。
#Python