[Mlir-commits] [mlir] [mlir][py] invalidate nested operations when parent is deleted (PR #93339)

Maksim Levental llvmlistbot at llvm.org
Fri May 24 14:59:06 PDT 2024


makslevental wrote:

> We had discussed also adding some kind of arena context manager that would hold all PyOperations allocated in its scope and allow you to invalidate them (or invalidate at scope exit).

This is workable I think? It allows peopel to control their exposure by narrowing and widening the scope (i think?). 

> I think the potential for dangling pointers that are induced by the bindings itself is the worst world and we need to exit that... As we've seen, the attempt to keep a parallel accounting itself is its own enemy due to pointer reuse.

Yea I agree with this one - the worst papercuts are the ones you can't see but can feel. At the python that's stuff that happens in the cpp. At least after the excision/removal of `liveOperations`, if you get a crash you can bisect the python to find where/how.

> In this case, unless if you can hook every way in c++ that an operation* can be invalidated or have some form of "weak opptr" semantics, there is no better way. 

Yea I was thinking well `shared_ptr` or something but of course `Operation*` would have to itself be behind that and it still wouldn't work because it won't pass through the C API.

> We could try some form of weak reference list to the PyOperation itself (ie. As in the arena thought experiment), but my guess is that the best use of that would be for some kind of safe mode where we could actively warn or except if mutations we know about are dangling. Without an explicit arena, though, it will be very noisy because the python GC is not precise.

How would that work? I think I vaguely understand that `Py_XINCREF`/`Py_XDECREF` is for something like that?

https://github.com/llvm/llvm-project/pull/93339


More information about the Mlir-commits mailing list