Re: Dynamic Loading and Unloading of EPICS Device Support and Record.

[Marty Kraimer <mrkraimer@comcast.net>]

On 09/08/2010 01:44 PM, Dalesio, Leo wrote:

Marty should chime in here too.
There were two large issues with dynamically adding records -
1) recomputing the lock sets - which was handled when modifying database links was implemented.
2) I believe was the record initialization and device support initialization issues. To be clear on this, it would be best to read through the record type and instance initialization, the device type and device instance initialization, and the driver initialization. Most likely, existing device and driver support would need to be reworked. For a while, I would just not write an initialization routine and take care of that in the read or write. That way I knew it could be done at any time.

I would not delete records. This really opens a can of worms. It would be more straight forward to disable them. Create a new alarm severity - disabled. Then the action to take on disabled can be configured. No channel access to it through access security rules for instance.
The deletion is more complex, as references to that record within an IOC, resolve to the memory location to improve the performance. A record does not know everyone that refers to it. To further complicate things, there are also state programs that would have to deal with records going away. Currently they support channel access disconnects - so perhaps this is not as difficult as I think.

In any case - start with being able to add them dynamically. If that goes well and you're feeling brave - then go for delete second.



-

Let me explain briefly how the javaIOC handles dynamic creation and deletion of database records.

Rather than lock sets each javaIOC record is locked. To handle links between records it is possible to lock one additional record besides the currently locked record. The implementation prevents deadlocks.

In addition any code that accesses a record must register itself by supplying a callback method named "detach".

Each record instance has a RecordProcess created for it. RecordProcess calls the top level Support which must exist. Each field can optionally also have a Support.
RecordProccess and Support implement the following methods: initialize, start,process, stop, and uninitialize. When initialize is called the support can create anything it requires for processing but can not access anything outside the record. Start can connect to things outside the record, e.g. hardware, other records, channel access, etc. Process is called when a record is processed. Stop undoes start. Uninitialize undoes initialize.


There are two databases involved with records that can be processed: master, and beingInstalled.

The following is done to delete a record: The record is removed from the master database. The detach method of all registered code is called. After detach is called the code must no longer access the record. Then RecordProcess.stop() is called. This results in all Support.stop() methods being called, Then RecordProcess.uninitialize is called which again results in all the Support.uninitialize methods being called. After this the record is gone.

To add a record, actually a set of records, the following is done: The records are added to the beingInstalled database. For each record the following is done: Look for all fields that have a request to replace the current PVField implementation. Ceates a RecordProcess for the the record and create the Support for all fields that have support. Then call RecordProcess.initialize and then RecordProcess.start,. If anything fails during this install quits. If all succeed then the beingInstalled records are moved to the master database. It is somewhat more complicated than this but not much.

The really big problems with the v3 IOC are: 1) lock sets, which span records, and 2) There is no equivalent in record support or device support to stop and initialize, and 3) There is no equivalent to detach.

For lock sets  I think it means the entire database must be locked while a record is added or deleted so that lock sets can be recomputed. There is already a global lock for the database which gets locked if a new access security file is loaded into a running IOC. I think I am remembering this correctly. But it does mean the entire database must be locked which makes everything freeze.

To support stop and unintialize all record/device code for any record to be added or deleted must be upgraded. In addition any code that accesses record instances must register and provide a detach method.

Sounds like a really big job.

As Bob says you could decide not to support record deletion. That removes the need to support stop and uninitialize and detach. That simplifies what must be done. But lock sets still appear to be a problem.

I would still  go with the idea of a beingInstalled database. One thing to remember, however, is that code that accesses other records (dbliink calink) must look in both master and beingInstalled when looking for local records.