Async widget methods deadlock due to on_msg not being called
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 5/5
- Tempo estimado
- Mais de uma semana
- Facilidade para iniciantes
- 25/100
Direção de pesquisa
Comece reproduzindo o caso de await de send/on_msg do widget e compare seu comportamento com IPython issue 12786 e ipykernel PR 589. Considera-se concluído quando o callback on_msg puder processar a resposta enquanto a célula aguarda, sem entrar em deadlock nem exigir uma segunda célula.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
We are developing a Jupyter widget which makes it possible to embed interactive Unfolded maps into notebooks:
Our widget is embedded via an iframe and so the communications with the JavaScript side are asynchronous. Some of the functions we want to add to the widget need to return data asynchronously. To communicate between Jupyter and JS we are using widget's send and on_msg methods. Our methods return futures. It works fine - the messages are being sent and received, but only if we do it in two steps:
When we are trying to use await so that we can have the results and do something with them within one cell, the execution is blocked forever:
We tried to investigate the cause. It turns out that the callback we register with widget.on_msg only gets called once the execution of the cell is finished. Hence, if we wait until we obtain the result of the calculation within the same cell where the method was called, we end up in a deadlock.
So far we've had no success in finding a workaround, despite trying many things. For instance, here we run the communication in a separate thread and wait until the query response is added to a blocking queue:
Calling the above function fails (after the 2 seconds timeout) with an error saying that the queue is empty:
And we don't see the _receive function being called.
However, if we check the queue immediately after getting this error, we can see that the queue is not empty - the response was added to it, apparently, just after the error caused the cell execution to be cancelled:
It might be the same issue as this one: https://github.com/ipython/ipython/issues/12786
but I am not completely sure. I tried installing and running the kernel with the fix from this PR, but I was getting errors related to traitlet messaging when trying to instantiate our widget.
- 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
-
essnmx good first issue
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 95/100
-
[Feature] 奇物选择添加优先级 Aberta
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 65/100
syfoud/Simulated_Scepter#174 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
Giskard-AI/giskard-oss#2840 · 1 comentário ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Abertaarea: repo bug perceived difficulty: 2
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
yeti-platform/yeti#1380 ·