What information do you wish the interpreter provided, that would make your program simpler and more reliable?
On Fri, Sep 28, 2018, 07:21 Gabriele <phoenix1...@gmail.com> wrote: > Hi Victor, > > > I understand that you are writing a debugger and you can only *read* > > modify, not execute code, right? > > I'm working on a frame stack sampler that runs independently from the > Python process. The project is "Austin" > (https://github.com/P403n1x87/austin). Whilst I could, in principle, > execute code with other system calls, I prefer not to in this case. > > > In the master branch, it's now _PyRuntime.gilstate.tstate_current. If > > you run time.sleep(3600) and look into > > _PyRuntime.gilstate.tstate_current using gdb, you can a NULL pointer > > (tstate_current=0) because Python releases the GIL.. > > I would like my application to make as few assumptions as possible. > The _PyRuntime symbol might not be available if all the symbols have > been stripped out of the binaries. That's why I was trying to rely on > _PyThreadState_Current, which is in the .dynsym section. Judging by > the output of nm -D `which python3` (I'm on Python 3.6.6 at the > moment) I cannot see anything more useful than that. > > My current strategy is to try and make something out of this symbol > and then fall back to a brute force approach to scan the .bss section > for valid PyInterpreterState instances (which works reliably well and > is quite fast too, but a bit ugly). > > > There is also _PyGILState_GetInterpreterStateUnsafe() which gives > > access to the current Python interpreter: > > _PyRuntime.gilstate.autoInterpreterState. From the interpreter, you > > can use the linked list of thread states from interp->tstate_head. > > > > I hope that I helped :-) > > Yes thanks! Your comment made me realise why I can use > PyThreadState_Current at the very beginning, and it is because Python > is going through the intensive startup process, which involves, among > other things, the loading of frozen modules (I can clearly see most if > not all the steps in the output of Austin, as mentioned in the repo's > README). During this phase, the main (and only thread) holds the GIL > and is quite busy doing stuff. The long-running applications that I > was trying to attach to have very long wait periods where they sit > idle waiting for a timer to trigger the next operations, that fire > very quickly and put the threads back to sleep again. > > If this is what the _PyThreadState_Current is designed for, then I > guess I cannot really rely on it, especially when attaching Austin to > another process. > > Best regards, > Gabriele > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/njs%40pobox.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com