[Openais] Re: event service code number 2

[Mark Haverkamp]

On Tue, 2004-08-31 at 17:16, Steven Dake wrote:
> On Tue, 2004-08-31 at 15:46, Mark Haverkamp wrote:
> > On Tue, 2004-08-31 at 15:26, Steven Dake wrote:
[...]
> > > 
> > > There is an extra extern clm_get_by_nodeid in exec/evt.c which shouldn't
> > > be necessary.
> > > 
> > Which one?
> > 
> 
> evt.c:152.  This is already defined in clm.h..  It would probably be
> better to include this in case the interface changes..

Sorry, I misunderstood.  I though that you meant that I had an extra
call to clm_get_by_nodeid.


[...]
> > > 
> > > In the library:
> > > the dispatch function has a pretty large message (message_overlay) that
> > > is stored on the stack.  It may be more desireable to allocate this in
> > > Initialize and keep it around or allocate it in dispatch.  Also, the
> > > message isn't large enough (right now its 128k, where the max message
> > > size is 256k and can be configured to be larger).  It would be nice if
> > > this were linked into the MAX_MESSAGE_SIZE global which shold probably
> > > go in gmi.h if its not there already.
> > 
> > I was just noticing this myself.  It was a while ago that I put that
> > in.  Weren't we going to have a saRecvQueueMalloc at some point?
> > 
> 
> Now saRecvQueue does the malloc correctly..  saRecvQueue/* shouldn't be
> used from a dispatch function though.  

What should I use instead, just saRecvRetry?


[...]
> > > evt.c:421 how can this case happen?  Shouldn't this be an assert instead
> > > of returning an error?
> > 
> > How about returning SA_ERR_NO_MEMORY?
> > > 
> 
> This is a better return code, but I'm still not sure how this condition
> occurs.

It probably shouldn't.  But if for some reason it does, it gives the
application the option to do something instead of just terminating it.

> 
[...]
> > > Comments for the future development:
> > > on the retaining of events you could add each event as a seperate entry
> > > in the timer list.  This may not be practical, I just dont know, but the
> > > timers are generic so if they don't get the job done, we need to get
> > > that fixed.  This would be more optimal then having two seperate timer
> > > loops and provide better short-duration operations (vs a long purge
> > > every second for thousands of events, purge them individually when there
> > > time comes due.  The timer functionality prefers timers that are short
> > > in duration, so the things that happen often wont be negatively affected
> > > by a large timer list.
> > 
> > If each retained message was on its own timer, The poll code would still
> > have to go through each one anyway.  I also need to have the list for
> > the implementation of the saEvtEventClearRetentionTime funciton.
> > 
> This isn't exactly true..  the poll code keeps timers in sorted order
> from earliest to expire to latest to expire.  While the cost is a little
> higher for additions (because the list must be searched for the correct
> spot) this only happens once, not every 1 second.  Then dispatch of the
> timer functions occur on the list until no more timers can be expired
> and stops.  ClearRetentionTime should be able to use the timer delete
> functionality.  In the case where there are alot of timers, this should
> help out interactivity, but the cost of searching may be minimal anyway
> (but I think searching 10k events may take awhile) even if it is as
> often as 1 second.

OK, Let me think about this while I am finishing the other updates.

Thanks,
Mark.


-- 
Mark Haverkamp <markh at osdl.org>