rpc inhibition

[Neal H. Walfield]

Marcus,

I have been think about inhibition.  Why do we need to cancel extant
RPCs when we inhibit RPCs?  It we could drop this requirement, it
would be easy to just use a read write lock instead of the complex
signal handling we use now.  When a worker thread wishes to use a
bucket, class or object, it gets a read lock.  When some process needs
to inhibit RPCs before it can continue, it gets a write lock (of
course, we make sure that write locks have priority over read locks).
Why bother?  Because this would seem to reduce code complexity.

In this message[1], you mention three uses of inhibition:

  - goaway
  - user RPCs like io_revoke, which need to iterate over all objects
  - privileged RPCs like remount

Do we really need to cancel pending RPCs in these cases?  Off hand, I
don't think so.  The only problem that I see is if there are
potentially unbounded extant RPCs.  Do we have any?

If we really need to cancel extant RPCs for some reason (but say only
on buckets), we could protect the inhibition lock with a mutex.  The
thread which wants to inhibit RPCs does:

  mutex_lock (&bucket->lock);

  if (! rwlock_wlock_try (&bucket->inhibition))
    {
       /* Cancel all pending rpcs on the bucket.  */
       rwlock_wlock (&bucket->inhibition);
    }

  mutex_unlock (&bucket->lock);

and readers do:

  mutex_lock (&bucket->lock);
  rwlock_rlock (&bucket->inhibition);
  mutex_unlock (&bucket->lock);


Reactions?

Thanks,
Neal

[1] http://lists.gnu.org/archive/html/hurd-devel/2003-10/msg00000.html