Hi Gabriele, If everything you are doing is pausing and restarting, there should be no reason why this would interfere with anything more than if you are doing this at any other time other than the interpreter initialization. The only thing I can think of is that at this stage locking is much more common.
The other thing that could be at play is that ptrace sends SIGSTOP on PTRACE_ATTACH but the signal cannot be captured by the interpreter (or any other process) so no signal handler should be at play either. Do you know what is involved in the deadlock (as in, what the threads are waiting on)? Answering your questions directly: > However, I think this poses one question: is this behaviour from Python to be expected or is it perhaps an indication of a potential bug? Is not expected or unexpected because is not something we support. Is not also something we explicitly forbid either, is just that there is nothing in the design or the test suite that ensures that this will work. > is it acceptable that the pausing and resuming of the execution of a thread lead to a potential deadlock? It depends if this is something that we can control in a reasonable way or if this is outside our control. It may be a bug in our code in which case we can try to fix it, but without a more concrete pointer is going to be complicated, especially given that is more likely that this is outside our control. We probably will reject any proposal to add complexity to support this use case but we likely will be happy to do small changes if there is something small that we do that is preventing the use case. Cheers from cloudy London, Pablo Galindo Salgado On Mon, 6 Jun 2022 at 15:38, Gabriele <phoenix1...@gmail.com> wrote: > Hi there > > I hope you don't mind me sharing my experience with testing the > austinp variant of Austin with Python >=2.7,<3.11. > > The austinp variant is a variant of Austin > (https://github.com/P403n1x87/austin) for Linux that uses ptrace to > seize and interrupt/continue threads to capture native stack traces > using libunwind. During testing, I have discovered that there are good > chances of causing what looks like a deadlock in Python if the seizing > and interrupting of threads happen very early when spawning a Python > subprocess from austinp. This seems to coincide with the > initialisation of the interpreter when modules are being loaded. To > avoid interfering so destructively with Python, I have added a sleep > of about 0.5s on fork to prevent sampling during this initialisation > phase, which has helped significantly. > > However, I think this poses one question: is this behaviour from > Python to be expected or is it perhaps an indication of a potential > bug? Whilst I find it conceivable that something like this could > happen, given the locking that happens around imports, is it > acceptable that the pausing and resuming of the execution of a thread > lead to a potential deadlock? > > Cheers, > Gabriele > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/EWE5IK53IAME7ODZOGCQGSSP4YBE37YX/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KH2CRDMPSRA4YHXQNQ4Z2WLSG3Y5IPMR/ Code of Conduct: http://python.org/psf/codeofconduct/
