poolPoll should not need a dedicated thread

Bug #541318 reported by Jeff Hill
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Andrew Johnson

Bug Description

> 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.


> -----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

Tags: ca vxworks
Revision history for this message
mdavidsaver (mdavidsaver) wrote :

Andrew, is this still relevant with currently supported vxWorks?

tags: added: vxworks
Changed in epics-base:
assignee: nobody → Andrew Johnson (anj)
status: New → Incomplete
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.