---
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.