• Establish common callback context struct
• Convert UDF callbacks to fetch module state from callback context

https://bugs.python.org/issue42064

Automerge-Triggered-By: GH:encukou

A couple of questions, @encukou:

• Do I need to ensure GIL is held in create_callback_context(), or can I get away with it like it is?
• Ditto for free_callback_context()

Do I need to ensure GIL is held in create_callback_context(), or can I get away with it like it is?

There are very few funcitons in the C-API that you can call without the GIL held; usually they're the ones needed before a GIL is created. For PyMem_Malloc/PyMem_Free specifically, there's a a big red warning to answer your question ;)
PyMem_Malloc is configurable; the default allocator relies on the GIL for synchronization.

There are very few funcitons in the C-API that you can call without the GIL held; usually they're the ones needed before a GIL is created. For PyMem_Malloc/PyMem_Free specifically, there's a a big red warning to answer your question ;)

Yes, I've seen it ;) But then why does this PR work as it is? (That is, without the GIL)

(FYI: I'll update the PR with GIL wrappers soon)

But then why does this PR work as it is?

I assume it's because you're not using multiple threads.
Even if you were, it might be rare to cause the memory allocator to run in two threads at once. But when it would, it'd crash quite spectacularly. (Or worse, if a malicious actor could cause it to happen.)

But then why does this PR work as it is?

I assume it's because you're not using multiple threads.
Even if you were, it might be rare to cause the memory allocator to run in two threads at once. But when it would, it'd crash quite spectacularly. (Or worse, if a malicious actor could cause it to happen.)

Ah, right. Thanks!

I've updated the PR. PTAL :)

On hold until #27613 has landed.

@encukou, this is now ready for review (again). PTAL.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.