poolPoll should not need a dedicated thread

> Do we really need a whole thread dedicated to doing this?

Agree that we don’t need a dedicated thread for this. I suspect this was written before the timer stuff was firmed up, we didn’t have at that time the concept of shared timer queue, and rsrv didn’t (doesn't) have a dedicated timer queue. It maybe is wise to make the server independent of the db stuff although this is certainly not a concern for rsrv.

Jeff

> -----Original Message-----
> From: Andrew Johnson
> Sent: Thursday, March 01, 2007 10:19 AM
> To: Jeff Hill
> Subject: Re: task priorities, busy cpu, and timeout
>
> Hi Jeff,
>
> Jeff Hill wrote:
> >>poolPoll 149 50=Medium ???
> >
> > On vxWorks the CA server attempts to always maintain a maximum free
> block
> > greater than 100 kB. The vxWorks functions analyzing pool to determine
> the
> > maximum free block are labor intensive. They are, from my perspective,
> too
> > labor intensive to be run every time that the ca server allocates memory.
> > Therefore a special poolPoll thread, analyzing the maximum free block
> > periodically, was installed. This is undoubtedly an imperfect protection,
> > but better than nothing.
>
> Do we really need a whole thread dedicated to doing this? It would save
> memory footprint and shouldn't affect performance to use the callback
> facilities in src/db. We could move the majority of that code into
> libCom if you don't want the server to depend on stuff in db.
> Alternatively just do it in a shared low/medium priority timer callback
> - on vxWorks there's only one CPU to do the work anyway, so you're not
> going to be able to avoid CPU contention.
>

Original Mantis Bug: mantis-286
    http://www.aps.anl.gov/epics/mantis/view_bug_page.php?f_id=286