質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.09%

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

解決済

回答 1

投稿 編集

  • 評価
  • クリップ 1
  • VIEW 583

score 164

定刻、一定間隔に関数を実行するモジュール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日の最後に クリアする「別の定刻処理」を 内部で勝手にスケジュール登録するようにしたいです。

【分からないこと】

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

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

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

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

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 1

checkベストアンサー

+1

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

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

これらを元に図を書くと以下のような感じでしょうか。
スレッドの概念図

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/06/25 21:30

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

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

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

    キャンセル

  • 2020/06/25 22:15

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

    キャンセル

  • 2020/06/26 06:34

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

    キャンセル

  • 2020/06/26 07:05

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

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

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.09%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る

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