Re: [PATCH v2] gdb/Python: Added ThreadExitedEvent

[Tom Tromey <tom@tromey.com>]

>>>>> Simon Farre via Gdb-patches <gdb-patches@sourceware.org> writes:

> So my reasoning for this was; since the thread is exiting it is dying,
> and from a Python perspective I thought it proper not to hold on to
> any resources that GDB otherwise would dispose of. I'm open to
> suggestions for whether or not this logic is sound.

gdb uses a maybe-weird approach to lifetime management.

Normally, a Python object isn't allowed to keep some underlying gdb
object alive.  So, if an inferior thread exits, the gdb data structures
will be cleaned up.  However, the InferiorThread wrapper object may live
on -- but now it is in a special invalid date.

This approach is why a bunch of types, like InferiorThread, have an
'is_valid' method.

So, it's fine to emit this event with the InferiorThread object.  If the
Python code capture it, that will be fine.  (Though of course this
probably won't normally happen anyway.)

gdb could probably be better about notifying Python about these
transitions to the invalid state.  I feel like there's some Python
protocol in this area that gdb should participate in but does not.
Like, it may be useful for using these objects as keys in a weak map.

> It's currently emitted inside `delete_thread_object` which is a
> function that is attached to the observer
> `gdb::observers::thread_exit` in py-inferior.c. So if we are to return
> a reference to the thread object, the function attached here should
> probably be removed entirely and replaced with just emitting the newly
> introduced "thread exit event" (and handle the de-allocation of the
> thread object inside the thread exit event type tp_dealloc function).

I think the current placement of the code is correct.  I'm not sure I
understand the tp_dealloc comment, but I don't think a change there is
needed.

Tom