Subject: |
Re: Channel access |
From: |
[email protected] (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 [email protected]
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:
<1994>
1995
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
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Changes to Stepper Motor Record Joseph P. Sullivan
- Next:
Re: sending strings to subrecords/device layer winans
- Index:
<1994>
1995
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
2021
2022
2023
2024
|