[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb-patches
Subject:    Re: [PATCH 1/3] gdbserver: hide fork child threads from GDB
From:       Pedro Alves <pedro () palves ! net>
Date:       2021-11-29 15:37:00
Message-ID: 342f0bb2-5b42-24e3-b2bf-a6d5e3a00e33 () palves ! net
[Download RAW message or body]

On 2021-11-29 12:46, Simon Marchi wrote:

> On 2021-11-26 17:51, Pedro Alves wrote:

>> Wonder whether we should instead have some:
>>
>>   thread_info *target_pending_child (thread_info *parent);
>>   thread_info *target_pending_child_parent (thread_info *child);
>>   target_waitkind target_pending_child_kind (thread_info *parent);
>>
>> target methods instead of moving the fields.  I haven't thought this
>> fully through, though.
> 
> At first I wasn't sure, I was thinking that having the fields directly
> in thread_info would help avoid duplication, in case another OS (e.g.
> NetBSD) decided to implement the same thing.  But not really: even if
> the fields are in thread_info, the bulk of the work (updating these
> fields) is done by the target.  Since the state is managed by the
> target, target methods make sense.
> 
> I will add a "target_thread_pending_parent" in this patch, a
> "target_thread_pending_child" in patch 3, and in your series you can add
> a way to get the kind.  Either a new method, or I was thinking of an
> output parameter on target_thread_pending_child.  Sounds good?

Yes, output parameter sound great.
[prev in list] [next in list] [prev in thread] [next in thread]