Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Wed, 15 Jun 2005 18:07:45 -0600

Ok, considering this further, yes I recall at our last meeting that we
considered that the vampire might tap in where the event is inserted into
the event queue so that it could run at database processing priority. If so,
then we would need to define an interface at that level which can be
installed instead of a conventional event queue. Alternatively, when
creating a CA client context we might add an option specifying that the
event poster should directly call the call back, and that an event queue
should not be interposed between the event poster and the client
application. Taking that further we could define an abstract event queue
interface that is passed when creating a ca client context, and an
application could provide whatever implementation they preferred. In the
vampire situation we might specify a NOOP event queue implementation
providing direct invocation of the callback by the event poster.

Jeff

-----Original Message-----
From: Jeff Hill [mailto:[email protected]] 
Sent: Wednesday, June 15, 2005 5:55 PM
To: 'Ralph Lange'; 'EPICS Core Talk'
Subject: RE: V4 Database Access

When the CA client library runs inside the IOC it communicates with the
database service directly (w/o going through a socket). The client library
also communicates directly with the IOC's event queue. Considering that, and
considering that the new client interface and the new service interface will
be very close to identical then perhaps we can conclude that your vampire
can insert its fangs using the CA client library interface. Or in any case
we should probably invalidate that approach before defining a new interface.

Jeff

-----Original Message-----
From: Ralph Lange [mailto:[email protected]] 
Sent: Wednesday, June 15, 2005 8:47 AM
To: EPICS Core Talk
Subject: V4 Database Access

Another thing that I recently found missing:

I think we agreed to introduce APIs between the IOC database and the CA 
server that allow
 - other (network) servers to register with the database (as listeners 
being interested in getting events)
 - other (database kind of) things to register as a new provider of 
"records" (i.e. named DA property catalogs)

Where's the new thing (module, service, handler?) that provides these 
interfaces?

Seen from 3.14, this takes over some of the functionality that has been 
in the database and some from Channel Access.
It should handle record name resolution and connection to DA interfaces 
(to handle requests coming in from servers).
It should also work as an event handler (broker?) that software modules 
(like a server or the Vampire) can subscribe to and the database can 
post its events to that get distributed to the registered listeners.

I'm not sure about the design as all this definitely sounds like a local 
cut-down version of channel access. If we introduce client-specified 
monitor deadbands - should handling these deadbands by client be moved 
from CAS down into that layer to make it available for other 
transports/servers?

I'm not trying to impose anything here ... it's just that the Vampire 
needs to intercept db_post_event() and add more channels to the IOC 
record namespace, and I don't know at which level that would be done.

Cheers,
Ralph

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System