179 lines
9.7 KiB
Markdown
179 lines
9.7 KiB
Markdown
---
|
|
id: AGD-0041
|
|
ticket: foreground-stack-game-pause-shell-vm-backed
|
|
title: Foreground Stack, Game Pause, and VM-Backed Shell Coexistence
|
|
status: accepted
|
|
created: 2026-06-05
|
|
resolved: 2026-07-03
|
|
decision: DEC-0037
|
|
tags: [runtime, os, lifecycle, shell, game, vm, foreground, architecture]
|
|
---
|
|
|
|
## Contexto
|
|
|
|
Durante a discussao da `DSC-0040` sobre separar VM e render worker, surgiu um caso que nao pertence somente ao render: `Game -> Shell -> Game`.
|
|
|
|
O caso minimo e:
|
|
|
|
- um Game esta rodando;
|
|
- o usuario aperta Home;
|
|
- o Game deve sair do foreground sem ser encerrado;
|
|
- o Hub/Shell assume a tela;
|
|
- o usuario pode abrir um app Shell, inclusive VM-backed;
|
|
- depois o usuario retorna ao mesmo Game.
|
|
|
|
O render worker precisa saber qual visual owner pode apresentar frames, mas a decisao principal e de lifecycle: quais VMs existem, quais podem executar, o que significa pausar um Game, e como Shell apps coexistem com um Game pausado.
|
|
|
|
Material relacionado:
|
|
|
|
- `DSC-0031`: separacao entre perfis Game e System/Shell.
|
|
- `DSC-0032`: SystemOS como autoridade de lifecycle/process/task.
|
|
- `DSC-0035`: janelas Shell pertencem a tasks e definem liveness do app.
|
|
- `DSC-0036`: Hub/Shell prova fatias de lifecycle.
|
|
- `DSC-0040`: render ownership/epoch durante transicoes e paralelismo VM/render.
|
|
|
|
## Problema
|
|
|
|
Precisamos definir o contrato de foreground para impedir ambiguidades como:
|
|
|
|
- Game pausado continuando a executar frames logicos enquanto Shell esta no foreground;
|
|
- Shell VM-backed competindo com Game por pacing, input, superficie ou render ownership;
|
|
- multiplos Shells foreground ou multiplos Games ativos sem uma politica explicita;
|
|
- retorno ao Game sem clareza sobre estado pausado, input, render invalidation e retomada da VM.
|
|
|
|
Sem esse contrato, a separacao VM/render da `DSC-0040` pode ficar tecnicamente correta, mas o SystemOS ainda pode permitir estados incoerentes.
|
|
|
|
## Pontos Criticos
|
|
|
|
- Existe apenas um foreground visual owner por vez.
|
|
- Background execution e outro assunto e deve ficar fora da primeira decisao, salvo se for necessario definir uma proibicao explicita.
|
|
- Shell VM-backed nao deve herdar politica de game loop so por usar VM.
|
|
- Game pausado provavelmente deve reter estado, mas nao deve consumir frames logicos.
|
|
- O Hub/Shell precisa ser capaz de rodar enquanto o Game esta suspenso.
|
|
- A transicao deve invalidar render submissions antigas para impedir present de frames obsoletos.
|
|
- O modelo precisa caber no SystemOS/lifecycle existente, nao diretamente no render worker.
|
|
|
|
## Opcoes
|
|
|
|
### Opcao A - Foreground unico, Game suspenso, Shell unico
|
|
|
|
- **Abordagem:** permitir no maximo um Game carregado e no maximo um Shell foreground; ao apertar Home, o Game entra em estado pausado/suspenso e Shell/Hub assume o foreground. Shell VM-backed pode executar apenas enquanto for o foreground Shell.
|
|
- **Pro:** modelo simples, previsivel e alinhado com console; reduz concorrencia real entre VMs; combina com a regra de render ownership unico.
|
|
- **Contra:** nao cobre multitarefa/background; futuras features de overlay ou apps persistentes precisarao expandir o contrato.
|
|
- **Manutenibilidade:** alta; SystemOS pode modelar uma pilha pequena de foreground/suspended sem virar scheduler generico.
|
|
|
|
### Opcao B - Multiplas VMs residentes, somente foreground executa
|
|
|
|
- **Abordagem:** permitir que Game e Shell VM-backed coexistam como VMs residentes, mas somente a entidade foreground executa. O Game pausado fica residente, sem tick; Shell VM-backed roda sob lifecycle Shell.
|
|
- **Pro:** preserva estado e permite retorno rapido; nao exige background execution.
|
|
- **Contra:** precisa contrato claro de memoria, ownership de input, foco, cancelamento e fechamento.
|
|
- **Manutenibilidade:** boa se os estados forem explicitos; ruim se a residencia for confundida com execucao em background.
|
|
|
|
### Opcao C - Encerrar Game ao entrar no Shell VM-backed
|
|
|
|
- **Abordagem:** Home fecha/salva o Game antes de abrir Shell VM-backed, evitando coexistencia.
|
|
- **Pro:** simplifica o runtime.
|
|
- **Contra:** quebra a expectativa de console moderno; torna `Game -> Shell -> Game` um reload, nao uma pausa.
|
|
- **Manutenibilidade:** simples no curto prazo, mas provavelmente gera mais excecoes e UX ruim depois.
|
|
|
|
### Opcao D - Background real desde ja
|
|
|
|
- **Abordagem:** permitir Game pausado ou Shell apps rodando em background com politicas de prioridade.
|
|
- **Pro:** cobre casos futuros ricos.
|
|
- **Contra:** amplia demais escopo: scheduler, budget, energia, audio, input, IO e memoria.
|
|
- **Manutenibilidade:** baixa para v1; mistura a decisao de foreground com multitarefa real.
|
|
|
|
## Sugestao / Recomendacao
|
|
|
|
Recomendo seguir com a combinacao das opcoes A e B:
|
|
|
|
- somente um Game residente por vez;
|
|
- somente um Shell foreground por vez;
|
|
- Game pode ficar pausado/suspenso enquanto Shell esta foreground;
|
|
- Shell VM-backed pode existir junto com Game pausado, mas segue lifecycle Shell;
|
|
- somente o owner foreground executa VM/tick/event loop conforme sua politica;
|
|
- background execution fica explicitamente fora de escopo;
|
|
- render ownership muda junto com foreground owner e deve invalidar submissions antigas via epoch/generation, conforme `DSC-0040`.
|
|
|
|
Isso preserva o ciclo `Game -> Home/Shell -> Game` sem transformar o runtime em multitarefa geral agora.
|
|
|
|
## Perguntas em Aberto
|
|
|
|
- [x] Qual e o nome canonico dos estados de Game fora do foreground: `Paused`, `Suspended`, ambos, ou outro?
|
|
- [x] Ao apertar Home, o Game deve receber um evento/interrupt/trap de pausa antes de parar de executar?
|
|
- [x] O Hub e um Shell especial sempre presente ou uma task Shell comum?
|
|
- [x] Um app Shell VM-backed pode substituir o Hub no foreground ou o Hub permanece como owner raiz?
|
|
- [x] Quando o Shell VM-backed fecha, o retorno vai sempre para Hub ou pode voltar diretamente ao Game?
|
|
- [x] O input do Game e drenado/limpo ao pausar e ao retomar?
|
|
- [x] Audio do Game pausa junto com a VM ou tem politica propria?
|
|
- [x] Existe limite de memoria/residencia para manter Game pausado enquanto Shell app roda?
|
|
- [x] O retorno ao Game exige novo frame antes de trocar a superficie, ou a tela pode manter Hub/Shell ate a primeira submission valida?
|
|
- [x] Quais eventos de lifecycle precisam ser visiveis para firmware, OS, VM e host?
|
|
|
|
## Resolucao
|
|
|
|
Fica aceito o modelo `Game -> Home/Shell -> mesmo Game` com foreground unico e
|
|
residencia limitada:
|
|
|
|
- somente um Game pode estar residente por vez;
|
|
- somente um Shell pode ser foreground por vez;
|
|
- Hub e o Shell root/especial e permanece owner raiz/back-stack;
|
|
- um Shell VM-backed pode assumir o foreground visual, mas segue lifecycle de
|
|
Shell e nao herda politica de game loop;
|
|
- fechar um Shell VM-backed retorna ao Hub em v1;
|
|
- background execution real fica fora de escopo;
|
|
- no host desktop, `Esc` e a tecla principal para solicitar Home/SystemOS e a
|
|
tecla fisica `Home` pode existir como alias;
|
|
- a acao Home/SystemOS e interceptada pelo host/SystemOS e nao entra no pad
|
|
logico visivel ao Game;
|
|
- `Paused` e o estado/evento cooperativo visivel ao Game;
|
|
- `Suspended` e o estado operacional imposto pelo OS/scheduler;
|
|
- ao sair do foreground, o OS notifica o Game para pausar e concede um budget
|
|
curto de reacao;
|
|
- se o Game nao reagir ao pause dentro do budget, o OS suspende a VM mesmo
|
|
assim;
|
|
- ao retornar, o OS reativa a VM, notifica o Game para resume/foreground
|
|
restore e permite que o Game sincronize antes de voltar ao gameplay;
|
|
- input pendente do Game e drenado/limpo nas fronteiras de pause/resume;
|
|
- audio do Game pausa junto com a VM em v1;
|
|
- retorno ao Game deve manter Hub/Shell visivel ate a primeira render submission
|
|
valida do Game retomado;
|
|
- render ownership muda junto com o foreground owner e invalida submissions
|
|
antigas via epoch/generation;
|
|
- firmware observa transicoes macro; OS observa lifecycle completo; VM observa
|
|
pause/resume; host observa owner/render epoch e estado de apresentacao.
|
|
|
|
## Criterio para Encerrar
|
|
|
|
A agenda pode ser encerrada quando tivermos uma decisao clara sobre:
|
|
|
|
- cardinalidade de Games e Shells residentes/foreground;
|
|
- semantica de Game pausado/suspenso;
|
|
- politica de execucao para Shell VM-backed durante Game pausado;
|
|
- regra de foreground visual owner e render invalidation;
|
|
- comportamento minimo do ciclo `Game -> Shell -> Game`;
|
|
- itens explicitamente fora de escopo, especialmente background execution real.
|
|
|
|
## Discussao
|
|
|
|
- 2026-06-05: Agenda criada a partir da `DSC-0040`, quando o caso de Shell VM-backed aberto sobre um Game pausado mostrou que a discussao pertence ao lifecycle/SystemOS, nao apenas ao render worker.
|
|
- 2026-07-03: Direcao provisoria aceita para as perguntas 2-10:
|
|
Game deve receber evento de pausa com budget curto antes da suspensao; Hub e
|
|
Shell root/especial; Shell VM-backed pode assumir foreground visual, mas Hub
|
|
permanece como owner raiz/back-stack; fechar Shell VM-backed retorna ao Hub em
|
|
v1; input do Game deve ser drenado/limpo em pause/resume; audio do Game pausa
|
|
junto com VM em v1; apenas um Game pausado residente e permitido; retorno ao
|
|
Game deve manter Hub/Shell visivel ate a primeira submission valida; firmware
|
|
ve transicoes macro, OS ve lifecycle completo, VM ve pause/resume, host ve
|
|
owner/render epoch e estado de apresentacao.
|
|
- 2026-07-03: Pergunta 1 permanece aberta para esclarecer se `Paused` e
|
|
`Suspended` sao estados distintos, nomes para camadas diferentes, ou se v1
|
|
deve expor somente um deles.
|
|
- 2026-07-03: Direcao proposta para pergunta 1: `Paused` e o estado/evento
|
|
cooperativo visivel ao Game; `Suspended` e o estado operacional imposto pelo
|
|
OS. Ao sair do foreground, o OS notifica o Game para pausar e concede um
|
|
budget curto de reacao; se o Game nao reagir, o OS suspende a VM mesmo assim.
|
|
Ao retornar, o OS notifica o Game antes de recoloca-lo no foreground visual,
|
|
permitindo sincronizacao/revalidacao. O Game nao controla a suspensao, mas
|
|
pode observar `pause`/`resume` para ajustar seu estado interno.
|