Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

thread_safe_bus.state (getter) should not use locks

Ouverte
#1,891 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
python
Domaine
networking

Piste de recherche

Commencez par lire thread_safe_bus.py et la propriété state présentée dans l’issue, puis suivez l’utilisation des verrous send et receive par le bus thread-safe. Déterminez si les lectures de state nécessitent une synchronisation indépendamment de ces verrous ; le travail est terminé lorsque les vérifications de state n’attendent plus le listener tout en restant sûres pendant des opérations send et receive concurrentes.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Python
Étoiles
1.6k
Forks
697
Aucune PR mergée en 30 j

Guide de contribution

Ouvrir le guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de hardbyte/python-can

Toutes les issues de hardbyte/python-can

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.