[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Johan Rydberg
Subject: Re: libhurd-cap-server/class-alloc.c
Date: Mon, 17 Jan 2005 10:43:02 +0100
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]