On Mon, May 24, 2021 at 4:31 PM Andreas Fritiofson <
[email protected]> wrote:

>
>
> On Wed, Feb 17, 2021 at 9:21 PM Tim Newsome <[email protected]> wrote:
>
>> On Tue, Feb 16, 2021 at 4:17 PM Steven Stallion via OpenOCD-devel <
>> [email protected]> wrote:
>>
>>> Out of curiosity, why even bother with a more advanced structure when a
>>> list will suffice? I agree it feels gross to iterate to find a given
>>> thread, however we're looking at a relatively low number of iterations. Is
>>> it really worth introducing an additional dependency to avoid a loop?
>>>
>>
>> A list is fine. But I don't want to have to implement that list. linux.c
>> implements its own list. list.h implements a slightly different list, but
>> doesn't implement look-up by a key.
>>
>
> struct thread *lookup(int id)
> {
>         struct thread *t;
>         list_for_each_entry(t, &threads, lh) {
>                 if (t->id == id)
>                         return t;
>         }
>         return NULL;
> }
>
>
>> I could build something on top of that list, or write my own from
>> scratch. That's just a big waste of effort though, given that there already
>> are fast, well-tested implementations out there.
>>
>
> I myself have spent far more time reading this email thread, checking out
> gnulib licensing and so on, than what it took to write that lookup
> function. Just saying... I'm not buying that "waste of effort" argument at
> all.
>

Part of my motivation was to get better than O(n) lookup times, but for
this particular application it doesn't matter much (until somebody has a
use case where it does, of course). Can you add some basic documentation to
list.h explaining overall how it's intended to be used? It just took me way
too long to figure out that you have to put a `struct list_head` to the
front of the structure you want to put in the list. Just a short bit of
code that makes a list, adds some entries, iterates, removes some entries,
and then frees the whole thing would be a great resource. I know that
exists in the code, but it's usually dispersed among different functions.

I'm inclined to just use the list and ignore performance, because I'm as
tired of this thread as you probably are. Nobody besides me seems to be
excited to have a hash map easily usable from OpenOCD.

Tim


Reply via email to