[Python-Dev] What is the purpose of the _PyThreadState_Current symbol in Python 3?

[Nathaniel Smith]

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 <phoenix1987 at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/njs%40pobox.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20180928/d6662e82/attachment.html>