Re: Changes to records during asynch processing

[Andrew Johnson <anj@aps.anl.gov>]

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
--
There are 10 types of people in the world:
Those who understand binary, and those who don't.