[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: ACL Performance (caching on object basis) (ITS#1523)
At 09:59 PM 2002-01-27, Howard Chu wrote:
>ITS #1523 does provide this pointer in addition to a cache of results of
>evaluating each ACL. The cache is maintained for a single operation on a single
>entry and then discarded.
I may have misinterpreted the code. I'm thinking the code
should be much simpler. Something like:
access_allowed should be called with a pointer to a ACLState
structure. This structure has three fields:
1) a pointer to the first "what" clause which is
value specific.
2) a pointer to the first "by" clause (within the
"what clause) which is value specific.
3) an access_mask prior to evaluation of this
"by" clause.
If NULL is passed instead of a pointer to the structure,
access_allowed() works as before. Otherwise,
The structure is allocated by the caller.
Prior to the first call for a particular target (with our without
values), the caller initializes the structure to { NULL, NULL, 0 }.
access_allowed() processes the ACL. When it comes across the
first value specific what/by clause, it records the what/by and
mask (prior to evaluation of the clause) and continues normally.
On second call, the structure is passed back into access_allowed().
As the pointers are non-NULL, access_allowed() jumps forward to
these clauses. It sets the mask to that provided in the structure
and continues with the evaluation (starting with clauses indicated).
Note that if the first call may result in NULL what/by clause
pointers. In this case, the caller should avoid making further
calls for this target (with or without values) as they will
evaluate the same as the first.
With a slight modification (and another state field), the burden
of avoidance could be shifted to access_allowed.
I suspect something simple like this would be quite effective
for most common ACLs.