Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

thread_safe_bus.state (getter) should not use locks

オープン
#1,891 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
python
領域
networking

調査の方向性

まず thread_safe_bus.py と issue に示されている state プロパティを読み、次に thread-safe bus で send ロックと receive ロックがどのように使用されているかを追跡します。state の読み取りに、これらのロックとは独立した同期が必要かどうかを判断します。send と receive の同時実行中も安全なまま、state のチェックが listener を待たなくなれば完了です。

索引モデルが issue の本文から書いたものです。

説明

enhancement
Problem description

I have a small application that listens on one thread, and may send on another (using asyncio). Before sending, I used to check the hardware state by evaluating the .state property. I use the thread safe bus.
However, this leads to long wait phases, depending on incoming messages.

It turns out that getting the .state property locks both send and receive locks, whereas lock_recv is probably occupied by the listener most of the time, which causes the delays.
in thread_safe_bus.py:

    @property
    def state(self):
        with self._lock_send, self._lock_recv:
            return self.__wrapped__.state
Proposed change

I am not very familiar with thread-safe communication in Python, but derived from my C++ knowledge, the value of the .state property is only an enum value and should be atomic anyway, especially when reading.
So from my point of view, I would either just return the value without locks. Or - if any locking is needed for some reason - use a separate state-access-lock that is independent from lock_send and lock_recv.

Workaround

I guess checking the bus state before each send() call is not the correct way to do. I switched to a mere send() and catch a CanError exception afterwards, which works fine without delay.

主要言語
Python
スター
1.6k
フォーク
697
PR マージ指標
30日以内にマージされた PR はありません

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

hardbyte/python-can のほかの issue

hardbyte/python-can の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。