Experimental Physics and
Industrial Control System

"Peregrine M. McGehee" <[email protected]> · Thu, 04 Sep 2003 07:53:51 -0600

Andrew,
Aren't the field sizes known by iocInit? If memory allocation
is needed it would occur here, i.e. once and only once, thus
no fragmentation issues.
One could imagine a scheme in which fixed sized queues (perhaps
as circular buffers) are allocated for fields of interest for
each record in the database.
The meaning of "of interest" is debatable, although a strawman
is every field that is not SPC_NOMOD.
This does seem to be a significant change to how record processing
works - although given the continued traffic it may be
worth real study.
- Peregrine
Andrew Johnson wrote:

Peregrine M. McGehee wrote:

I concur with [Tim's] fundamental idea and suggest that the .RPRO
field should contain a _list_ of structures to support
multiple writes from clients during the period when PACT==1.
The naive implementation is a simple FIFO queue for write requests,
although in general this should be a priority queue.

I'm afraid this idea is a very long way from being as simple as it might
seem, because of memory fragmentation issues. Marty has already posed
the major issue - where are you going to save the values to put into the
fields, especially as the data can be an array? To do that, you have to
continually malloc and free memory, which currently only the Channel
Access server does and then only when creating and destroying the tasks
that maintain the network connection to a new client.
There are no calls to memory allocation routines inside the database
runtime engine, precisely because continually doing that leads to memory
fragmentation. We need EPICS to be capable of building systems that
have uptimes of many months or more, and memory fragmentation problems
would kill that existing capability.
Benjamin is right - we need to kill this gnat of a problem without
blowing our own heads off in the process, which means a lot of thinking
and testing of any radical changes. Marty does have a very good
understanding of the issue, and is now proposing a relatively simple
solution that reflects the caching nature of Channel Access (i.e. only
the last value will be retained if the data target is busy). Anything
more complex is not likely to be suitable for R3.14.x IMHO.
- Andrew

--
Peregrine M. McGehee	[email protected]	(505) 667-3273
Sloan Digital Sky Survey / Spallation Neutron Source
MS H820, Los Alamos National Laboratory, Los Alamos, NM 87545

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System