At 03:33 PM 6/17/2005, Howard Chu wrote:
> I'm still questioning the current code (from connection.c rev
> 1.265) which removes some of Abandon's exemptions from the defer
> check. Since ultimately processing the Abandon will free up
> resources. I think it should always go through, and we need to
> give the same treatment to Unbind.
Some of the restrictions were put in place for non-obvious reasons.
For instance, one of the reasons we defer Abandon during Bind is
because the Bind operation itself is not abandonable. Of course,
clients which issue requests while Binding, especially non-anonymous
Binds, are quite broken. Which is another reason I never paid much
attention to this case.
If we place some restrictions on what kind of operations abandon can
abandon, then we give some more exemptions to Abandon. For instance,
if we restrict abandoning to only search requests, then things get
easier. (Cancel can cancel more (but not all) kinds of operations.
But let's take on separately.)
And, as far as thread restrictions, I disagree that an exemption
should be given. Abandon will use additional resources to do its
work, and that's why the thread restriction should apply.
> I'm not sure we can do anything about Cancel since we haven't
> parsed the request OID by the time we make the decision about
> deferring the operation. We could try parsing the OID earlier but
> that seems ugly. It also seems like a minor issue, and we can just
> leave things the way they are. It seems the main reason Cancel was
> implemented here was to allow terminating a Persistent Search
> operation, and for that purpose it will still work fine.
The main purpose of Cancel is replace completely the function of
Abandon, which suffers from not having any indicator of success or
failure. Of course, Cancel (and Abandon) are generally only useful
when the operation is log-lived, such as a subtree search, a subtree
rename, or some chained operation (in which case, the cancel should
be chained).