thread_safe_bus.state (getter) should not use locks
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 35/100
- Tipo de issue
- Bug
- Clareza
- Razoavelmente clara
- Status de atividade
- Estagnada
- Stack de tecnologia
- python
- Domínio
- networking
Direção de pesquisa
Comece lendo thread_safe_bus.py e a propriedade state mostrada na issue; em seguida, rastreie como os locks de send e receive são usados pelo bus thread-safe. Determine se as leituras de state exigem sincronização independentemente desses locks; considera-se concluído quando as verificações de state não esperam mais pelo listener, mantendo-se seguras durante operações concorrentes de send e receive.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
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.
- Linguagem predominante
- Python
- Estrelas
- 1.6k
- Forks
- 697
- Métricas de merge de PRs
- Nenhum PR com merge em 30d
Preparar o ambiente
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de hardbyte/python-can
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 88/100
hardbyte/python-can#2103 ·
-
bug
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 78/100
hardbyte/python-can#2077 · 1 comentário · 1 reação ·
-
bug
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 68/100
hardbyte/python-can#1922 · 1 reação ·
-
enhancement
Dificuldade 3/5 1-2 dias Facilidade para iniciantes 75/100
hardbyte/python-can#2104 ·
-
enhancement
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 30/100
hardbyte/python-can#2102 ·
Todas as issues de hardbyte/python-can
Issues semelhantes
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
-
bug
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 88/100
qgis/QGIS-Plugins-Website#459 ·
-
bug severity:medium
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
Mantenedores costumam responder em até 2 dias
-
bot-found bug priority: P3
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 84/100
madenvel/KalinkaPlayer#179 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 68/100
ls1intum/edutelligence#1098 ·
Mantenedores costumam responder em até 1 dia