Agenda - [PERF] Async Background Work Lanes for Assets and FS

Problema

asset.load() hoje cria uma thread do SO por requisicao. Ao mesmo tempo, fs ainda nao tem uma politica clara para sync assincrono barato em hardware simples.

O projeto precisa de paralelismo para IO/decode/sync, mas o target inclui handheld DIY e hardware barato, onde um pool grande ou explosao de threads pode piorar a latencia em vez de melhorar.

Dor

thread::spawn por request escala mal e cria jitter.
assets e fs competem por IO sem uma politica unica de fila/prioridade.
sem lane dedicada, operacoes de background tendem a vazar custo para o main loop.
sem disciplina, o host desktop vira referencia errada para hardware fraco.

Hotspots Atuais

Alvo da Discussao

Fechar um modelo de execucao assincrona para asset e fs que seja previsivel em hardware simples.

O Que Precisa Ser Definido

Topologia de workers. Escolher entre:
- uma thread dedicada para asset e outra para fs;
- um worker unico multiplexando filas;
- um pool minimo e fixo;
- proibicao explicita de spawn por request.
Separacao por dominio. Decidir se asset e fs compartilham scheduler/fila ou se cada dominio tem lane propria.
Politica de prioridade. Definir:
- prioridade de loads visuais vs audio;
- prioridade de sync de save/config;
- limite de trabalho por frame para install/commit.
Modelo de retorno. Fechar como o guest observa backlog, cancelamento e saturacao:
- status imediato de fila cheia;
- status de pending;
- metrica de backlog;
- politica de cancelamento.
Orçamento para hardware barato. Definir quantas threads o runtime pode assumir como baseline.

Open Questions de Arquitetura

O v1 precisa de lanes separadas para asset e fs ou basta uma fila central com classes de prioridade?
Decode de asset fica no mesmo worker do IO ou em fase distinta?
Commit/install no device continua no main thread por determinismo?

Dependencias

../specs/09-events-and-concurrency.md
../specs/15-asset-management.md
../specs/16a-syscall-policies.md
014-app-home-filesystem-surface-and-semantics.md

Criterio de Saida Desta Agenda

Pode virar PR quando houver decisao escrita sobre:

numero e tipo de workers aceitos no baseline;
fila/prioridade de asset e fs;
proibicao ou aceitacao limitada de thread::spawn por request;
modelo de status/telemetria para backlog e saturacao.

3.1 KiB Raw Blame History