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 sill would be the right place.
So, in short: will HSH_Private really persist?
Nils
_______________________________________________
varnish-dev mailing list
[email protected]
https://www.varnish-cache.org/lists/mailman/listinfo/varnish-dev
