RFC: Server should execute requests on a thread pool when client does not specify an execution thread

Abierto
  • ¿Algo no está bien?
#281 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
cpp
Área
backend-api-design, distributed-systems

Línea de trabajo

Comienza con la transcripción de external-interfaces y el comportamiento actual de ThreadMap.makeThread y Context.thread descrito en el issue. Determina el diseño del thread pool del lado del servidor y sus efectos sobre los thread handles ausentes, los métodos sin mp.Context, los callbacks y el orden de las respuestas; se considera terminado cuando exista un RFC o un plan de implementación acordado, ya que no se especifican archivos ni tests.

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

Descripción

Referencing: https://btctranscripts.com/bitcoin-core-dev-tech/2026-05/external-interfaces

Problem: IPC interface can be awkward to call due to threading

  • Clients have to choose which thread asynchronous calls execute on, and create threads for calls to execute on
  • Could be improved by server executing requests on a thread pool when client does not specify an execution thread

Currently, clients that call IPC methods must first call ThreadMap.makeThread to create a server-side worker thread and pass the resulting Thread handle in Context.thread on every call so it executes on a dedicated thread. Libmultiprocess abstracts this away for C++ clients, but clients that don't use libmultiprocess (which only supports C++) must handle this setup manually, making the IPC interface more awkward to call.

Proposed improvement: When a client passes a null/missing Context.thread, or when a method has no mp.Context parameter at all, the server should fall back to executing the request on a server-managed thread pool instead of blocking the event loop thread or failing with "invalid thread handle". This would simplify non-libmultiprocess clients that doesn't need a dedicated thread model.

Caveats:

  • Callbacks require the client to still provide Context.callbackThread
  • Response ordering is not guaranteed when requests from the same client land on different pool threads. The dedicated thread model avoids this by always queuing requests from the same client on one thread
Lenguaje dominante
C++
Estrellas
62
Forks
58
Merge medio
6 d 11 h
PR fusionados (30 d)
7

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

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 bitcoin-core/libmultiprocess

Todos los issues de bitcoin-core/libmultiprocess

Issues similares

Más issues de C++

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.