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

[Tom Tromey <tom@tromey.com>]

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

> Tom requested that I should probably just emit the thread object;
> I ran into two issues for this, which I could not resolve in this patch;

> 1 - The Thread Object (the python type) checks it's own validity
> by doing a comparison of it's `thread_info* thread` to nullptr. This
> means that any access of it's attributes may (probably, since we are
> in "async" land) throw Python exceptions because the thread has been
> removed from the thread object.

This seems fine to me, because the event emission comes before the
clearing of the field:

+  if (!evregpy_no_listeners_p (gdb_py_events.thread_exited))
+    {
+      if (emit_thread_exit_event (tmp->thread_obj->thread) < 0)
+	gdbpy_print_stack ();
+    }
   tmp->thread_obj->thread = NULL;

The InferiorThread object is valid until that NULL assignment is done.

> 2 - A python user can hold a global reference to an exiting thread. Thus
> in order to have a ThreadExit event that can provide attribute access
> reliably (both as a global reference, but also inside the thread exit
> handler, as we can never guarantee that it's executed _before_ the
> thread_info pointer is removed from the gdbpy thread object),
> the `thread_info *` thread pointer must not be null. However, this
> comes at the cost of gdb.InferiorThread believing it is "valid" - which means,
> that if a user holds takes a global reference to that
> exiting event thread object, they can some time later do `t.switch()` at which
> point GDB will 'explode' so to speak.

I think it will be fine because thread-switching checks validity using
THPY_REQUIRE_VALID.  So once the underlying (gdb) thread is gone, the
InferiorThread will be in the "invalid" state, and all will be fine.

Another way to look at it is that the user can already stash the
InferiorThread somewhere and refer to it later.

The reason I think it's better to pass the InferiorThread to the event
is that (1) it means you can have a map where the key is a thread and
then it is easy to update when a thread exits, and (2) this doesn't lose
anything because the event can always refer to the members of the thread
if that is what is useful.

Tom