capabilities and client ids

[Neal H. Walfield]

Hi Marcus,

As I understand client IDs, the entry that a server allocates in the
current bucket's client_entry array serves as a client's client ID.  I
don't understand what is won by using this as opposed to the task ID
of the client.  It seems to be a gratuitous level of indirection which
only introduces overhead.

For any given bucket, the relation between task IDs and client IDs is
bijective.  So, in the very least, I don't think we need to expose the
client ID to the user.  (Exposing a client ID would be useful if a
single task could have multiple client IDs in which case the relation
between task ids and client ids would no longer be one to one.)
Having clients use their task id rather than their client id has two
advantages for the client: it is another piece of information clients
don't need to keep track of and it frees some bits in the message.  On
the server side, this eliminates the check to make sure the client
passed the right client ID.

Client IDs act as an index into the client entry table (which consists
of data structures containing a pointer to the client data and a
reference count).  A client entry always points to exactly one client
data structure and a client data structure always points to the client
entry (indirectly via the client->id index).  The relationship between
client entry data structures and client data structures is a
bijection.  This is different from capabilities identifiers where a
capability entry is useful: a capability entry is per client and
multiple capabilities entries can point to a single capability and as
such a capability must potentially maintain a list of pointers to
capability entries.  Given this observation, it makes sense to unify
the client entry and client data structures especially given that we
already have a hash in the bucket from the task id to the client data
structure (client_reverse).

I will post a patch which implements these changes in the near future
unless you voice some objections.

Thanks,
Neal