This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Implement 'detach pid'.


On Friday 14 November 2008 01:49:17 Pedro Alves wrote:
> On Thursday 13 November 2008 21:58:49, Vladimir Prus wrote:
> > Â/* Iterator function to call a user-provided callback function
> > - Â once for each known thread. Â*/
> > + Â once for each known thread. ÂReturns 0 to continue iteration,
> > + Â and 1 to stop -- which causes iterate_over_threads to return
> > + Â the current thread_info. Â*/
>
> To be honest, this sounds a bit confusing to me: the iterator function,
> which is what was being described in the first sentence isn't the
> same subject of the second sentence, "returns 0 ..." is now talking
> about the callback.
>
> > Âtypedef int (*thread_callback_func) (struct thread_info *, void *);
> > Âextern struct thread_info *iterate_over_threads (thread_callback_func,
> > void *);
>
> Notice that a few gdbthread.h exported functions are also
> documented in thread.c.  In this case:
>
> /*
>  * Thread iterator function.
>  *
>  * Calls a callback function once for each thread, so long as
>  * the callback function returns false.  If the callback function
>  * returns true, the iteration will end and the current thread
>  * will be returned.  This can be useful for implementing a
>  * search for a thread with arbitrary attributes, or for applying
>  * some operation to every thread.
>  *
>  */
>
> If we're moving the descriptions around, please, let's do
> that as a separate patch.

Ok, I'll drop this part. I can never get accustomed to the practice to
documenting interface inside implementation files :-)

> > +void
> > +mi_cmd_target_detach (char *command, char **argv, int argc)
> > +{
> > + Âif (argc != 0 && argc != 1)
> > + Â Âerror ("Usage: -target-detach [thread-group]");
> > +
> > + Âif (argc == 1)
> > + Â Â{
> > + Â Â Âstruct thread_info *tp;
> > + Â Â Âchar *end = argv[0];
> > + Â Â Âint pid = strtol (argv[0], &end, 10);
> > + Â Â Âif (*end != '\0')
> > +ÂÂÂÂÂÂÂerror (_("Cannot parse thread group id '%s'"), argv[0]);
> > +
> > + Â Â Â/* Pick any thread in the desired process. ÂCurrent
> > +ÂÂÂÂÂÂÂ target_detach deteches from the parent of inferior_ptid. Â*/
>
>                             ^ detaches.
>
> > + Â Â Âtp = iterate_over_threads (find_thread_of_process, &pid);
> > + Â Â Âif (!tp)
> > +ÂÂÂÂÂÂÂerror (_("Thread group is empty"));
>
> Yep, something like that.
>
> I take that it's OK then to not revert back to the
> previous thread?

Yes, --thread work the same way.

- Volodya


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]