Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

Bound request and discovery concurrency and share failed in-flight interpreter probes

Aberta
  • Algo errado?
#539 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
5/5
Tempo estimado
Mais de uma semana
Facilidade para iniciantes
35/100
Tipo de issue
Refatoração
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
rust
Domínio
backend, devtools, performance

Direção de pesquisa

Start with request handlers in crates/pet/src/jsonrpc.rs, path workers in crates/pet/src/find.rs, Conda fan-out in crates/pet-conda/src/lib.rs, and probe caching in crates/pet-python-utils/src/env.rs; compare the existing helper in crates/pet-core/src/cache.rs. Review dependencies #530, #533, and #536 before selecting a scheduler. Done means bounded, non-deadlocking work, shared success and failure probes, explicit overload and shutdown behavior, and preserved streaming and refresh semantics.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

enhancement

Tracking plan: #528
Priority: P2. Evidence: source-confirmed unbounded fan-out; quantify scaling impact with #533 before selecting limits.

Problem

RPC handlers create an OS thread per request. Discovery creates additional scoped threads per workspace/search path, and Conda discovery creates per-environment workers. Refresh coalescing shares identical work but does not bound unrelated requests, waiting threads, or nested locator fan-out.

Interpreter resolution serializes by cache-entry mutex, but an unsuccessful probe is not published to its existing waiters as a shared result. A burst targeting one failing executable can repeatedly incur the same expensive timeout rather than share one attempt.

Sources: request handlers, path workers, Conda fan-out, probe cache locking, existing single-flight cache helper.

Scope

Introduce bounded request/discovery/process work using the simplest scheduler compatible with streaming results and current platform support. Avoid nested-pool deadlocks and avoid queueing one OS thread per blocked request. Define admission/backpressure, fairness, shutdown, and operation deadlines explicitly; an async-runtime migration is not a prerequisite.

Share the outcome of one in-flight interpreter probe with concurrent waiters, including failure, without permanently negative-caching an executable that may later become valid. Distinguish a caller's deadline from the lifetime of shared work.

Acceptance criteria

  • Representative large inventories and request bursts remain within documented worker/process/queue bounds, measured by #533.
  • Same-key successful and failing probes execute once per in-flight group; later independent requests can retry failures.
  • Different keys can progress concurrently; nested discovery cannot deadlock the scheduler.
  • Lightweight control requests remain responsive during slow discovery; overload produces an explicit, documented outcome.
  • Shutdown/cancellation does not leak children or leave refresh joiners permanently waiting.
  • Locator priority, complete inventory, refresh coalescing, and early streaming remain correct, with no material small-workload latency regression under #531.

Dependencies

Depends on #530 for safe probe lifecycle, #533 for measurable workload/resource bounds, and #536 for coherent request ownership. Coordinate with #535 so moving glob expansion off the dispatcher does not create unbounded traversal threads.

Linguagem predominante
Rust
Estrelas
207
Forks
45
Merge médio
1d 4h
PRs com merge (30d)
18

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

  • Sem Dockerfile nem arquivo Docker Compose
  • Sem modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de microsoft/python-environment-tools

Todas as issues de microsoft/python-environment-tools

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.