Situação
Hoje a vida do servidor está amarrada à vida da sessão de depuração. Reiniciar o servidor obriga a reiniciar a sessão inteira, e não há como recarregar o gamemode mantendo o depurador anexado.
O painel do PawnPro (NullSablex/PawnPro#87) contorna encaminhando "Reiniciar" para workbench.action.debug.restart — funciona, mas é contorno, não solução.
Por que a limitação não é essencial
Lendo o código, a amarra vem de uma escolha de implementação, não do protocolo:
O que prende: o servidor é Child do adaptador, e ServerChild::drop o mata (main.rs:101). No Linux há ainda PR_SET_PDEATHSIG. Isso serve para limpeza — evitar servidor órfão se o adaptador morrer — e faz sentido nesse papel.
O que de fato conecta: o canal plugin↔adaptador é um socket local nomeado, derivado de PAWNPRO_DBG_SESSION:
- o plugin escuta (
bridge.rs:99, com listen_with_retry para o caso do socket anterior ainda estar sendo liberado)
- o adaptador conecta, e já tem retry de até 1 minuto sem bloquear o loop DAP (
plugin_client.rs:113)
Ou seja: a identidade da sessão é o nome do socket, não o parentesco de processo. Um servidor novo que suba com a mesma PAWNPRO_DBG_SESSION abriria o mesmo canal — e o adaptador, que já sabe reconectar, poderia reanexar.
Proposta
Separar quem mata de quem identifica:
- Um comando DAP de restart do alvo (
restart já existe no protocolo, ou um request customizado). O adaptador mata o Child atual, sobe outro com a mesma session, e deixa o plugin_client reconectar pelo caminho de retry que já existe.
- Breakpoints sobrevivem porque vivem no adaptador, não no processo — é o mesmo estado que o
setBreakpoints já mantém entre pausas.
- O
Drop continua como está: ele é a rede de segurança para o encerramento da sessão, e não atrapalha um restart deliberado.
Ganho para quem usa: recompilar o gamemode e recarregar sem sair da sessão — o ciclo mais comum ao depurar.
Incógnitas
- O
.amx muda no restart; o AMX_DBG precisa ser recarregado (o plugin já lê de PAWNPRO_DBG_AMXDBG, então talvez baste subir com o caminho novo).
- Breakpoints por linha continuam válidos se o arquivo mudou? Provavelmente exigem reenvio, o que o DAP já prevê.
listen_with_retry existe justamente porque o socket demora a liberar — vale medir se o intervalo entre matar e subir é suficiente.
Registro de proposta, não de bug. Nada quebrado hoje: o contorno funciona, e isto é sobre tirar uma limitação que não precisa existir.
Situação
Hoje a vida do servidor está amarrada à vida da sessão de depuração. Reiniciar o servidor obriga a reiniciar a sessão inteira, e não há como recarregar o gamemode mantendo o depurador anexado.
O painel do PawnPro (NullSablex/PawnPro#87) contorna encaminhando "Reiniciar" para
workbench.action.debug.restart— funciona, mas é contorno, não solução.Por que a limitação não é essencial
Lendo o código, a amarra vem de uma escolha de implementação, não do protocolo:
O que prende: o servidor é
Childdo adaptador, eServerChild::dropo mata (main.rs:101). No Linux há aindaPR_SET_PDEATHSIG. Isso serve para limpeza — evitar servidor órfão se o adaptador morrer — e faz sentido nesse papel.O que de fato conecta: o canal plugin↔adaptador é um socket local nomeado, derivado de
PAWNPRO_DBG_SESSION:bridge.rs:99, comlisten_with_retrypara o caso do socket anterior ainda estar sendo liberado)plugin_client.rs:113)Ou seja: a identidade da sessão é o nome do socket, não o parentesco de processo. Um servidor novo que suba com a mesma
PAWNPRO_DBG_SESSIONabriria o mesmo canal — e o adaptador, que já sabe reconectar, poderia reanexar.Proposta
Separar quem mata de quem identifica:
restartjá existe no protocolo, ou um request customizado). O adaptador mata oChildatual, sobe outro com a mesmasession, e deixa oplugin_clientreconectar pelo caminho de retry que já existe.setBreakpointsjá mantém entre pausas.Dropcontinua como está: ele é a rede de segurança para o encerramento da sessão, e não atrapalha um restart deliberado.Ganho para quem usa: recompilar o gamemode e recarregar sem sair da sessão — o ciclo mais comum ao depurar.
Incógnitas
.amxmuda no restart; oAMX_DBGprecisa ser recarregado (o plugin já lê dePAWNPRO_DBG_AMXDBG, então talvez baste subir com o caminho novo).listen_with_retryexiste justamente porque o socket demora a liberar — vale medir se o intervalo entre matar e subir é suficiente.Registro de proposta, não de bug. Nada quebrado hoje: o contorno funciona, e isto é sobre tirar uma limitação que não precisa existir.