HSH_Private (resent)

[Nils Goroll]

(resent because my initial mail did not make it to the mailing list)

Hi phk,

I am working on the patch for the expire superseded objects feature which I had 
been asked to send. In preparation for this, I am looking at recent changes.

68a424092d589932c782c9514d340f1752f094a5 introduces HSH_Private and private_oh 
for private objects, which before simply had a NULL objhead and were not 
inserted into any objhead list.

I hope to understand the intention behind the change and see that this could be 
useful for debugging, but I fail to understand why what it buys is worth the price:

- yes, it does remove some special casing in some places, but adds some in
   others.

- private_oh->mtx now is a congestion point for all private object creation,
   unbusy and deref

   We have got a class of customers who need to pass most requests and, with
   previous code, see virtually no lock contention. Wouldn't this change quite
   drastically - in particular as there are probably tens of thousands of
   objheads when caching, but there is only one private_oh for all passes?

- in particular unbusy on an OC_F_PRIVATE will needlessly grab the mtx and move
   the oc to the front of the private_oh


Regarding the actual patch I am working on: This was most efficiently done in 
HSH_Lookup when (oc->objhead == NULL) was still valid:

- remove oc from oh while holding the oh->mtx anyway
- NULL oc->objhead
- EXP_Rearm outside oh->mtx
- deref oh

With HSH_Private, IIUC avoiding a second lock of oh->mtx is not possible any 
more, so I wonder if HSH_Lookup still would be the right place.


So, in short: will HSH_Private really persist?

Nils