Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Using async changes thread for non-async callbacks which is unexpected

Abierto
#1,939 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
python
Área
networking

Línea de trabajo

Empieza por can/notifier.py en las líneas referenciadas de _rx_thread() y sigue _on_message_received() junto con la ruta de programación de asyncio. Revisa los issues #1938 y #1912 junto con este cambio. Se considera terminado cuando los callbacks no async puedan permanecer en el hilo de recepción de CAN cuando así se configure, mientras que los callbacks async se programen de forma segura desde cualquiera de los dos hilos sin cambiar el comportamiento predeterminado.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

bug

Using the can library with async enabled Notifier change the thread which all callbacks is called from. Without async, the notifier callbacks are run in the thread of the can rx thread. With async, it runs the callbacks via loop.call_soon_threadsafe() which cause the notifier callbacks to be run in the main async thread instead. This changes behavior for all callbacks, not just async callbacks, which is unexpected. E.g. if using a non-async can protocol stack plus another async protocol stack together might create problems due to the change of callback threads.

https://github.com/hardbyte/python-can/blob/5d62394006f42d1bf98e159fe9bb08d10e47e6eb/can/notifier.py#L111-L119

I propose a fix that prevents the async call_soon_threadsafe in Notifier._rx_thread() with the introduction of a setting run_message_reception_in_eventloop. Then the user can chose to opt out of running the regular non-async callbacks in the asyncio main thread. The default should be True so we don't change the current behavior.

def _rx_thread(self, bus: BusABC) -> None:
    # determine message handling callable early, not inside while loop
    if self._loop and self.run_message_reception_in_eventloop:              # <--- NEW
        handle_message: Callable[[Message], Any] = functools.partial(
            self._loop.call_soon_threadsafe,
            self._on_message_received,  # type: ignore[arg-type]
        )
    else:
        handle_message = self._on_message_received

A change is required in Notifier._on_message_received(). This function might be called in either threads, so calling the asyncio coroutine must be made thread safe:

def _on_message_received(self, msg: Message) -> None:
    for callback in self.listeners:
        res = callback(msg)
        if res and self._loop and asyncio.iscoroutine(res):
            # Schedule coroutine
            # In __init__: self._tasks: set[asyncio.Task] = set()
            task = asyncio.run_coroutine_threadsafe(res, self._loop)

When looking at this, #1938 and #1912 should be addressed in the same round.

Lenguaje dominante
Python
Estrellas
1.6k
Forks
697
Métricas de merge de PR
Sin PR fusionados en 30 d

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de hardbyte/python-can

Todos los issues de hardbyte/python-can

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.