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

Aperta
  • Qualcosa non va?
#281 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Tranquilla
Stack tecnologico
cpp
Ambito
backend-api-design, distributed-systems

Direzione di ricerca

Inizia con la trascrizione di external-interfaces e con il comportamento attuale di ThreadMap.makeThread e Context.thread descritto nell’issue. Determina il design del thread pool lato server e i suoi effetti sui thread handle mancanti, sui metodi senza mp.Context, sui callback e sull’ordinamento delle risposte; il lavoro è completato quando esiste un RFC o un piano di implementazione concordato, poiché non sono indicati file o test.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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
Lingua principale
C++
Stelle
62
Fork
58
Merge medio
6g 11h
PR unite (30g)
7

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di bitcoin-core/libmultiprocess

Tutte le issue di bitcoin-core/libmultiprocess

Issue simili

Altre issue su C++

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.