Re: libhurd-cap-server/class-alloc.c

[Johan Rydberg]

Marcus Brinkmann <address@hidden> writes:

>> hurd_cap_class_alloc manipulates the object slab
>> (i.e. CAP_CLASS->OBJ_SPACE) but does not lock the class.  Since the
>> locking interface is not exported, callers can't be expected to lock
>> the class.  Here is a patch to change hurd_cap_class_alloc to lock
>> CAP_CLASS.  Okay to check in?
>
> Funny enough, locking is not required, as the slab space already is
> protected by its own internal lock.

It's Neal opinion that there is no need for a internal lock in the
slab space.  If I recall correctly, we (me and Marcus) have discussed
this off-line earlier.

Anyway, the reason for having a lock in the slab space is to protect
it when the system goes low on memory and need to reap any slabs that
are fully free (i.e., no outstanding allocated objects.)  This, at
this point imaginary, function needs to be invoked from the pager.

There are, as I see it, three reads to go; 

  1) keep the lock,
  2) provide a hook to hurd_slab_space that will lock any other 
     structures or,
  3) provide a pthread_mutex_t* to hurd_slab_space.

Personally, I do not have a problem with keeping the lock for now
since the overhead of taking it is probably minimal.  And I suppose
this issue can be postponed until the self-pager shapes up.

~j