Re: [PATCH RFC] process/thread/lwp id patch - phase 3

["Eli Zaretskii" <eliz at is dot elta dot co dot il>]

> Date: Fri, 4 May 2001 02:06:41 -0700
> From: Kevin Buettner <kevinb@cygnus.com>
> 
> I know from conversations with some of my colleagues that this
> representation is not unanimously favored.  One of the alternate
> suggestions was to make struct ptid somewhat more opaque by making it
> more difficult to associate meaning with the various components.  (I
> guess this could be called "opacity through obscurity".)  Such a
> representation might look like this:
> 
>     struct ptid
>       {
>         long ids[3];
>       }

I don't like such techniques.  They don't really work (how many
seconds will it take to understand what does each element of ids[]
serve for?).

I think it's good enough to encapsulate access to these entities in a
bunch of functions, like you did, and leave the rest to be enforced by
the coding standards.

Plus, we can add something to the ARI script to help reveal any
``bad'' practice that succeeds to sneak in, if that's a real danger.

> +int
> +ptid_equal (ptid_t ptid1, ptid_t ptid2)
> +{
> +  return (ptid1.pid == ptid2.pid && ptid1.lwp == ptid2.lwp
> +          && ptid1.tid == ptid2.tid);
> +}

You could have passed pointers to the objects instead, and gain a bit
more performance.  In particular, you could compare the pointers
first, and if they are equal, skip the rest.  But that is not a very
important consideration, I think.