poseidon-server-review

name

poseidon-server-review

description

Revisão focada da camada de servidor e ciclo de vida do Poseidon — orquestração start/stop (Poseidon.Net.HttpServer), API fluente nativa (Poseidon.Native.Server), grupos de rotas (Poseidon.Native.Group), graceful reload (Poseidon.GracefulReload) e a fachada de seleção de backend de I/O (Poseidon.Net.IO). Use ao auditar Listen/Stop/Destroy, teardown sob carga, composição de rotas/middlewares/grupos, troca de handler/config em voo e a fronteira camada fluente ↔ dispatcher. Segue a Regra de Ouro de poseidon-review (só reporte o que provar).

Revisão da camada de servidor do Poseidon

Escopo: Poseidon.Net.HttpServer.pas, Poseidon.Native.Server.pas, Poseidon.Native.Group.pas, Poseidon.GracefulReload.pas, Poseidon.Net.IO.pas. Aplique a Regra de Ouro de poseidon-review: só reporte o que puder PROVAR (cenário concreto + linha exata). Marque a plataforma afetada — HttpServer seleciona o backend por {$IFDEF} (IOCP/RIO no Windows, epoll/io_uring no Linux), então um bug de start/stop pode existir só em uma delas.

O que caçar

Ciclo de vida (Listen / Stop / Destroy)

• Listen idempotente? Chamar duas vezes vaza socket/thread ou levanta?
• Stop seguido de Destroy: ordem de liberação. O backend de I/O é parado ANTES de liberar pools/managers que suas threads ainda tocam? Um worker em voo acessando FServer/pool já liberado é use-after-free (CRITICAL).
• Destroy sem Listen prévio (construído e liberado): nenhum nil deref.
• Sinalização de parada: evento/flag lido pelas IO-threads com barreira de memória adequada (não um Boolean cru sem TInterlocked/volatile semantics).
• Drain gracioso (R-1): requisições em voo terminam antes do socket fechar? Novas conexões são recusadas durante o drain?

API fluente (Native.Server)

• Get/Post/Put/Delete/Use: registro de rota/middleware é permitido APÓS Listen? Se sim, a estrutura de rotas é thread-safe contra as IO-threads que fazem Lookup (ver Router). Registro concorrente com serving → corrida.
• TNativeMiddlewareEntry guarda MethodPtr OU FuncPtr conforme IsFunc: confirme que a chamada respeita o discriminador (chamar o ponteiro errado é call em nil/lixo).
• Captura de variáveis em closures de handler/middleware: reference to captura por referência — variável de loop capturada compartilhada é bug clássico.
• Propriedades de segurança/limite (MaxRequestSize, MaxQueueDepth, AllowedMethods, SecureHeaders, ServerBanner, RateLimit): lidas pelo dispatcher a cada request — set após Listen cria corrida de leitura/escrita.

Grupos (Native.Group)

• Composição de prefixo: concatenação de path evita // duplo e prefixo sem /.
• Middlewares do grupo aplicados na ordem certa e SÓ às rotas do grupo.
• TNativeGroupBlock (bloco anônimo): o grupo é liberado/estável durante o registro? Ponteiro para o servidor pai não dangla.

Graceful reload

• Troca de handler/config sob carga: publicação atômica do novo conjunto de rotas. Uma IO-thread lendo o ponteiro antigo enquanto o novo é instalado — o antigo continua válido até o último leitor terminar? (RCU/refcount ou lock). Sem isso: use-after-free ou rota parcialmente instalada servida.
• Recarga não deve derrubar conexões keep-alive existentes sem necessidade.

Fachada de I/O (Net.IO)

• Seleção de backend por {$IFDEF}: cada plataforma resolve para uma unit real existente; não deixar um branch referenciando símbolo inexistente na outra.
• Tipo de retorno/registro consistente entre backends (a fronteira comum não pode assumir um campo que só um backend preenche).

Não reporte sem provar

Uma "corrida no shutdown" só é bug se você apontar as duas threads, a ordem de acesso e o campo compartilhado tocado após liberação. Um "vazamento no Stop" só conta se houver um caminho em que o recurso alocado não é liberado — mostre-o.