86 lines
3.1 KiB
Markdown
86 lines
3.1 KiB
Markdown
---
|
|
id: AGD-0008
|
|
ticket: perf-async-background-work-lanes-for-assets-and-fs
|
|
title: Agenda - [PERF] Async Background Work Lanes for Assets and FS
|
|
status: open
|
|
created: 2026-03-27
|
|
resolved:
|
|
decision:
|
|
tags: []
|
|
---
|
|
|
|
# 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
|
|
|
|
- [asset.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/console/prometeu-drivers/src/asset.rs#L353)
|
|
- [tick.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/console/prometeu-system/src/virtual_machine_runtime/tick.rs#L53)
|
|
- [runner.rs](/Users/niltonconstantino/personal/workspace.personal/intrepid/prometeu/runtime/crates/host/prometeu-host-desktop-winit/src/runner.rs#L315)
|
|
|
|
## Alvo da Discussao
|
|
|
|
Fechar um modelo de execucao assincrona para `asset` e `fs` que seja previsivel em hardware simples.
|
|
|
|
## O Que Precisa Ser Definido
|
|
|
|
1. 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.
|
|
|
|
2. Separacao por dominio.
|
|
Decidir se `asset` e `fs` compartilham scheduler/fila ou se cada dominio tem lane propria.
|
|
|
|
3. Politica de prioridade.
|
|
Definir:
|
|
- prioridade de loads visuais vs audio;
|
|
- prioridade de sync de save/config;
|
|
- limite de trabalho por frame para install/commit.
|
|
|
|
4. 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.
|
|
|
|
5. Orçamento para hardware barato.
|
|
Definir quantas threads o runtime pode assumir como baseline.
|
|
|
|
## Open Questions de Arquitetura
|
|
|
|
1. O v1 precisa de lanes separadas para `asset` e `fs` ou basta uma fila central com classes de prioridade?
|
|
2. Decode de asset fica no mesmo worker do IO ou em fase distinta?
|
|
3. 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.
|