Python: メインから払出した定刻処理の各々について、実行状況を各定刻処理側で 把握する手立てを確認したいです（scheduleとthreadingのモジュールのはなし）

Question

定刻、一定間隔に関数を実行するモジュールscheduleと、マルチスレッドを可能にするthreadingのモジュールの使い方について　質問です。
（https://teratail.com/questions/272118で対策方針を導き、こちらで技術的な解決策を導きたくお問い合わせさせて頂きました）

schedule.every().～で　幾つものスケジュールを登録して、最後に　下記のような実行監視用途の関数を実行する例をよくみかけます。

def time_count(self):
    while not self.stop_flag:
        schedule.run_pending()
        time.sleep(1)

        dt_now = datetime.datetime.now()
        print(dt_now.strftime("%X"))

今回、上記一連のあとに　当該アプリケーションが　ループに入ってしまうため、
アプリ利用者とのやりとりが遮断されてしまわないよう　最後の関数実行を　別スレッドとして実行する手立てを採用しています（threading）

【達成したいこと】

登録されたスケジュールを１日の最後に　クリアする「別の定刻処理」を　内部で勝手にスケジュール登録するようにしたいです。

【分からないこと】

1日の最後に動作させる　スケジュールクリアのための定刻処理の関数は、内部で（schedule.clear()の実施前に）
schedule登録されていて直前まで起動が果たされたscheduleの完了を待つ必要がある認識です。

また、thread.joinというメソッドで　払出したスレッドについて、払出し側から　その完了（払出したスレッド）を待つことができる認識をしています。
この結果からして...上記方針を達成する上で　払出し側のスレッドが　すべての定刻処理で同一になるため　このメソッドは　利用不可？ということになるでしょうか？？

また、ここが一番分からないのですが
1日の最後に動作させる　スケジュールクリアのための定刻処理だけ　先に紹介したtime_count関数を　別のスレッドで実行させる手立ても無きにしも非ずと考えるのですが、同一時間帯に、スレッドが別であろうと　schedule.run_pending()　が存在していて　良いの？？　というところが疑問です。

当問合せ文を記載しながら今までに頂いたご見解を思い出したのですが、こういう制御は　固定名ファイルの配置・存在確認で回避する手立てが一般的でしょうか？？

Answer 1

マルチスレッドで迷い始めたら図を書くことを推奨します。
自分ならどうするかを考えてみました。

• タイムテーブルにしたがってJOBを起動するスレッドJobDispatcherを作成する
• JobDispatcherスレッドは00:00に起動し23:59に終了させる(23:59にJOBが終わっていない場合はjoinで待つ)
• タイムテーブルの登録・削除はJobDispatcherスレッドの外、すなわちメインスレッドで行う
• JobDispatcherスレッドはメインスレッドから起動する
• メインスレッドは無限ループによりJobDispatcherが終了したらすぐにタイムテーブルの削除、再登録を行いJobDispatcherを再起動する

これらを元に図を書くと以下のような感じでしょうか。

Comments

[saya24]

yymmtさん、いつもお世話になっております。一つのスレッドを高低差を付けて起動と終了を表し、実行期間も横に展開できるこの絵、良いですねぇ。初めてみる図です。

仰られている方針は、私が掲載した　メインとは異なる単一スレッドで　各々のスケジュール処理の状況をしろうとする手立てでは無いので　24時付近に待てる・Thread.joinを使えるわけですよね。

理解があっていると嬉しいです。

[saya24]

同一スレッド内で複数登録されるスケジュールがあっても　時系列を崩さない　待ち行列をつくるから、スケジュール同士で互いを待つような手立ては不要らしい！　知らなかったなぁ

[yymmt]

> 理解があっていると嬉しいです。
すでに待ち行列の話が出ているので詳細は不要と思いますが、この提案の本質は「スケジュールに関するスレッドは1つ」とすることで問題を単純化することです。上の図をよくみてもらうとわかりますが下2つは実は同じスレッドです。

[saya24]

Thread2でスケジュールの登録と監視、2つを行なっている点ですね。この2つという点が当初の私の認識は　これなら監視側から完了を意識しできるな、と解釈した背景でした。

まだまだ何か勉強が足りなそうな感じがしました、この面を取り扱う記事をもう少し確認していこうと思います、ありがとうございました。