[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: prioritize operations; stop & defer running threads?
On Sat, 2006-05-20 at 03:35 -0700, Howard Chu wrote:
> Suspending in the overlay before any other processing begins shouldn't
> be too hard. Suspending a long-running search and resuming it would be
> tricky, but I suppose paged-results already addresses that.
>
> Your overlay will have to maintain its own high/low priority queues, and
> keep track of operations that get deferred multiple times (prevent
> starvation). Rather than pushing operations back onto the frontend
> connection's op queue you might maintain them totally privately in your
> overlay, with an Abandon handler to remove any that get abandoned,
> etc.Your overlay's response handler can then move ops off your priority
> queues back to the connection handler when you decide to run them.
>
> Or just push deferred ops to the tail of the connection's op queue, that
> may be simpler in general.
In general, I don't like confining in a custom (i.e. not generally
useful) overlay features that may be of general use (at least because
it's less painful to maintain and reuse them). So I'm thinking about a
generic mechanism that resides somewhere slapd and that may be of use in
other cases, while not too intrusive (e.g. by default all operations
have the same priority and no special handling occurs). What I'd like
to have is a call that says: "defer this operation with priority X",
where X is a number (could hijack 1 to 99 from Linux, or use
sched_get_priority_{min,max}() where available, and use the average as
default.
I'll be playing with this a little bit.
Thanks, p.
Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati@sys-net.it
------------------------------------------