Re: [PATCH 4/4] Documentation for python method InferiorThread.thread_handle

[Tom Tromey <tom at tromey dot com>]

>>>>> "Kevin" == Kevin Buettner <kevinb@redhat.com> writes:

Kevin> +@defun InferiorThread.thread_handle (type)
Kevin> +Return the thread object's handle.  Since handles are generally opaque
Kevin> +objects, the type @var{type} is used to ensure that the correct amount
Kevin> +of space is allocated for the returned handle value.  When using handles
Kevin> +associated with the pthreads library, the value passed for @var{type}
Kevin> +should be the result of invoking @code{gdb.lookup_type('pthread_t')}.
Kevin> +@end defun

This API requires the Python programmer to know the type of the
inferior's thread ID.  However, it seems to me that the target also
knows it, or should know it, and so there should be no reason to pass in
the type.

But if a handle is supposed to be opaque, why have a type at all?  It
could just be a bunch of bytes, or even just some completely opaque
object...  but if a completely opaque object would do, why not use the
InferiorThread itself?

I think the code patches all look good.  I didn't even have any nits.
However, exposing some API to Python is more of a commitment and so I'd
like to understand this area and come to an agreement about how it
should work before anything here goes in.

thanks,
Tom