Argonne National Laboratory

Experimental Physics and
Industrial Control System

<19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index <19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: Channel access
From: hill@luke.atdiv.lanl.gov (Jeff Hill)
Date: Tue, 28 Jun 94 14:09:23 MDT
> My question is if a channel access client does not call ca_task_exit()
> when it exists or if it crashes will there be "un-freed" memory on
> an IOC?
> 

The answer to this question varies depending on whether the client
is running under vxWorks communicating with local process variables
or not.

If the client's host is not the same as the process variable's host then
the answer is: to guarantee that all resources in the server are released for
future clients the client does not need to call ca_task_exit(). In 
fact the server will release resources whenever it detects that
the client's TCP/IP circuit is no longer active. Typically 
if there is a client exit or crash the server will rapidly detect that
the circuit is dead unless you keep the process active in a debugger.
The only exception to this occurs if the client's host crashes or is 
turned off (and does not immediately reboot). In this case the
CA server TCP/IP circuit loss detect will be tied to the vxWorks 
TCP/IP keep alive timer. The default TCP/IP keep alive timeout
is often set to half an hour.

If the client and the process variable have the same host then
resources are released by either a vxWorks task exit handler 
or a call to ca_task_exit(). The task exit handler is called if the
task that called ca_task_initialize() goes away or either of the
two auxiliary task spawned by ca initialization go away.
Note that under vxWorks if a task crashes it will frequently
end up suspended and this will not trigger CA's vxWorks exit handler.

Also note that by design the majority of the CA server's dynamic memory
allocation occurs off of a free list. CA starts out with an empty
free list and calls calloc() to obtain blocks from the system pool.
When a client disconnects CA places the released blocks on a free
list. Thus if you observe the consumption of memory with memShow() 
you will see that while CA will reduce the amount of free memory
in the system to accommodate a high client load it will not 
call free() and return this memory to pool when the client
load decreases. Instead this memory is placed on a free list
so that we avoid fragmentation problems and client initialization
costs.

Under EPICS 3.12 the CA server now refuses new connections when
the system pool's largest free block drops below 100k as 
analyzed by a vxWorks pool traversing system call every 5 sec.

Hope this helps.

Jeff


______________________________________________________________________
Jeffrey O. Hill			Internet	johill@lanl.gov
LANL MS H820			Voice		505 665 1831
Los Alamos, NM USA 87545	FAX		505 665 5107

Navigate by Date:
Prev: Re: Changes to Stepper Motor Record Joseph P. Sullivan
Next: Re: sending strings to subrecords/device layer winans
Index: <19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: Changes to Stepper Motor Record Joseph P. Sullivan
Next: Re: sending strings to subrecords/device layer winans
Index: <19941995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·