he problem, which I've
only seen during interpreter initialisation. So perhaps Python itself
is off the hook!
On Mon, 6 Jun 2022 at 19:20, Barry Scott wrote:
>
>
>
> On 6 Jun 2022, at 17:52, Gabriele wrote:
>
> I've found it hard to give an answer to this question. B
I should have clarified that this is just a plain fork/exec from C:
https://github.com/P403n1x87/austin/blob/e3d79ddc9f9737a791362e6962b5cac25a4e3dc2/src/py_proc.c#L972-L1010
Cheers,
Gabriele
On Mon, 6 Jun 2022 at 16:30, Victor Stinner wrote:
>
> On Mon, Jun 6, 2022 at 4:35 PM Gabriele wr
ython 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?
Cheer
Does this mean that this line in the bytecode library is likely to fail
with 3.11, with no way to fix it?
https://github.com/MatthieuDartiailh/bytecode/blob/7b0423234b0e999b45a4eb0c58115b284314f46b/bytecode/concrete.py#L398
On Fri, 1 Apr 2022, 10:40 Victor Stinner, wrote:
> I created https://bu
atible way. However, I am not very
satisfied with the way I have implemented this for now, nor can I
think of a better solution.
Cheers,
Gabriele
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python
Hi Fabio
Does the actual function object get re-created as well during the
recompilation process that you have described? Perhaps it might help
to note that the __code__ attribute of a function object f can be
mutated and that f is hashable?
Cheers,
Gabriele
On Thu, 17 Feb 2022 at 19:33, Fabio
> That's already the case for 3.11
Ah, that's awesome news! Like with the rest, I'll wait and see what shape this
ends up taking :).
Cheers,
Gab
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@pytho
rhaps there could be benefits
from the locality of reference, although it's not obvious to me why this
would be the case at the moment).
Best,
Gabriele
On Mon, 20 Dec 2021 at 20:16, Pablo Galindo Salgado
wrote:
> Hi Gabriele,
>
> In addition to what Guido and Brandt have already
stack: either iterate over
CFrame.previous, or the more traditional PyFrameObject.f_back. I
suspect there are reasons why these are perhaps not actually
equivalent, and indeed this is mainly what I'd like to read in the
literature I've requested above.
Cheers,
Gabriele
--
"Egli
the new field added. I'm happy to do the work myself if it gets
accepted.
Cheers,
Gabriele
On Sat, 17 Apr 2021, 11:07 Victor Stinner, wrote:
> Hi,
>
> There are two reasons:
>
> * PyThread_get_thread_native_id() was only added recently (Python 3.8)
> * PyThread_get_th
y the struct pthread over to
local VM and then guess where the tid field might be. So, if there's
no fundamental reason for thread_id to be PyThread_get_thread_ident, I
would like to propose to change it to PyThread_get_thread_native_id
instead.
Thanks,
Gabriele
--
"Egli รจ scritto in li
Ah ok, this might be related to Victor's observation based on the
latest sources. I haven't tested 3.7 yet, but if _PyRuntime is
available from dynsym then this is already enough.
Thanks,
Gabriele
On Sat, 29 Sep 2018 at 11:00, Nathaniel Smith wrote:
>
> On Fri, Sep 28, 2018 at 3
On Fri, 28 Sep 2018 at 23:12, Nathaniel Smith wrote:
> What information do you wish the interpreter provided, that would make your
> program simpler and more reliable?
An exported global variable that points to the head of the
PyInterpreterState linked list (i.e. the return value of
PyInterprete
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, es
h for finding a valid
PyInterpreterState, is there a more reliable approach for the version of
Python that I'm targeting?
Thanks,
Gabriele
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscri
On 5/19/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
>
> [snip]
>
> Waiting for comments!
Awesome, Georg! Wow. Nice work.
Seems like this has been a long time comin', and I bet others have
been working away "in secret" on similar projects. I hope you keep
running with it until it gets hijacked int
16 matches
Mail list logo
