On Tue, Jan 25, 2000 at 08:28:12PM +0100, [EMAIL PROTECTED] wrote:
> > Wow! In which area do you need more levels? Are you aware of
> > inactivity watchers?
>
> Hm, what does this question mean? I never used them, the doc says "not yet
> documented", and a mailing list scan reported that they are quite difficult to use
> .... Maybe I missed something. What is the point I should check more carefully?
Ah, well, in that case:
Inactivity watchers are similar to idle watchers. The difference is
that they judge idleness by whether there have been any events with
priority higher than the threshold level, where the threshold level is
a configurable attribute.
> > ASYNC 0 1 2 3 4 5 6 7 IDLE
> > HIGH NORM
>
> Oh, level 7 seems to be undocumented, I will try it ;-)
Oops! No, that is my mistake. Silly me, I forgot I was counting from
zero. No wonder the diagram lacked symmetry.
> This is a state
> machine, and I just recognized that I will possibly have to split it up into several
> state machines - this means more idle watchers of different priorities (certain
> states are more important than others because timeouts are running). So, having more
> priority levels would give me a better granularity to order watcher executions.
>
> Of course, choosing a watchers priority (and constructing a hierarchy of them) is a
> difficult task because priority reflects importance, but has to take care of event
> frequency, too. If high level events occur very often, lower levelled ones may never
> be serviced.
It sounds like your events stay queued long enough that priority
matters. That's pretty strange. I always thought of priority as a
subtle way to fine-tune the system. I can't help but wonder if there is
a more effective way to do what you want. Are the idle watchers
repeating? Do you set the min & max attributes? Have you watched the
event processing with NetServer::ProcessTop?
> To find a compromise - I think a number between 10 and 15 would be ok for now. It
> may be increased again if necessary.
Like this?
ASYNC 0 1 2 3 4 5 6 7 8 9 IDLE
HIGH NORM
> But, by the way, how about making this an
> installation parameter? The installer may decide which number of priority levels he
> prefers - knowing that this will influence performance.
That would cause trouble because many different unrelated modules need
to be able to offer reasonable default priorities to their events.
Changing the number of levels is akin to a major API change.
--
"Never ascribe to malice that which can be explained by stupidity."
via, but not speaking for Deutsche Bank
