Different child termination behavior during Kernel shutdown on Posix and Windows systems
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 35/100
- Tipo de issue
- Funcionalidade
- Clareza
- Razoavelmente clara
- Status de atividade
- Estagnada
- Stack de tecnologia
- python
- Domínio
- operating-systems
Direção de pesquisa
Comece em ipykernel/kernelbase.py por volta das linhas 1216-1227 e rastreie como _process_children() é usado durante o encerramento do Kernel. Compare a filtragem de grupos de processos do POSIX com o caminho de processos filhos do Windows e avalie a configuração proposta no nível da instância. O trabalho estará concluído quando o ciclo de vida desejado para kernels personalizados puder ser suportado, preservando o comportamento padrão existente.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Hello,
I've developed a custom Kernel inheriting from the IPython Kernel. This Kernel initiates a child process, and I aim to manage this process' lifecycle independently of the Kernel's shutdown workflow. To achieve this independence, I start the child process as a new process group. This approach functions as expected in POSIX systems, as the IPython Kernel verifies if the kernel process group is distinct from the child process group. However, a divergence in behavior arises when attempting the same workflow on Windows. This discrepancy stems from the IPython Kernel's behavior of returning all children of the Kernel process and subsequently sending SIGTERM signals to them. Please refer:
https://github.com/ipython/ipykernel/blob/main/ipykernel/kernelbase.py#L1218:L1227 and https://github.com/ipython/ipykernel/blob/main/ipykernel/kernelbase.py#L1216:L1217
I understand that it is not straightforward to determine the process group equivalence in Windows OS without using lower-level win32 APIs but this difference in behavior is causing issues in my custom kernel workflows.
Can I achieve my requirements without having to make any changes to the IPython Kernel? My proposed solution involves introducing an instance-level variable in the base Kernel class, which, if set to False, ensures that the Kernel refrains from terminating child processes by default during Kernel shutdown.
Here's a potential implementation:
self.terminate_all_children: bool = True # Set to true by default to maintain backward-compatibility
This variable is then checked in the _process_children() method to determine whether to process the children or not.
kernel_process = psutil.Process()
all_children = kernel_process.children(recursive=True)
process_group_children = []
if not self.terminate_all_children:
return process_group_children
else:
if os.name == "nt":
return all_children
kernel_pgid = os.getpgrp()
for child in all_children:
try:
child_pgid = os.getpgid(child.pid)
except OSError:
pass
else:
if child_pgid == kernel_pgid:
process_group_children.append(child)
return process_group_children
By setting terminate_all_children to False in the subclass, I ensure that the IPython Kernel doesn't terminate the child process by default when Kernel shutdown is initiated.
I'd appreciate your thoughts on this proposed solution. If it aligns with your expectations, I'm prepared to submit a PR. Thank you in advance!
- Linguagem predominante
- Python
- Estrelas
- 734
- Forks
- 411
- Merge médio
- 1d 2h
- PRs com merge (30d)
- 9
Guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de ipython/ipykernel
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 72/100
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 48/100
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 68/100
-
ipython/ipykernel#1550 · 1 comentário · 1 reação · 1 responsável ·
Todas as issues de ipython/ipykernel
Issues semelhantes
-
bug confirmed issue
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
open-webui/open-webui#30750 · 1 comentário ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
-
enhancement
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
OpenwaterHealth/openmotion-bloodflow-app#604 · 1 comentário ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
-
good first issue
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 90/100