Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Tue, 16 Mar 2004 12:46:55 -0700

Hello Ben,

> The CA client reference manual says: "The user's connection 
> state change function will be run immediately from within
> ca_create_channel if the CA client and the server are both 
> hosted within the same address space (within the same process)."
> 

As the code is written today, if your CA client application is running in an
IOC and a database field is located that matches the name of the channel
then the connection callback handler is called immediately from within
ca_create_channel().

If it isn't possible to easily rearrange your code to circumvent these
difficulties then please send another email describing the situation in more
detail. If the current situation is causing an unavoidable hassle then I
will need to consider alternatives.

> (1) From the above follows that if (for whatever reason) 
> the connection handler waits for an event that will happen only 
> after ca_create_channel completes, the application will be deadlocked. 

It's certainly possible to cause problems if you are blocking in a callback.

> Is this also the case if CA is used multi-threaded, i.e. 
> initialized with the ca_enable_preemptive_callback flag?

Yes, the behavior does not change if preemptive callback is enabled.

> 
> (2) Does a similar rule apply to ca_change_connection_event if
> previously ca_create_channel was called with a NULL connection handler?

The ca_change_connection_event() installs the new connection handler
function pointer, but does not cause the function to be invoked. That occurs
only when the connection state of the channel changes.

> 
> Btw, ca_change_connection_event is nowhere mentioned in the new CA
> client reference. I hope it was just forgotten and is not deprecated.

As you have discovered, use of ca_change_connection_event() in
multi-threaded applications can be problematic, and IMHO its not a high
quality interface in single threaded situations either. Therefore, future
use of this interface is being discouraged. 

> 
> (3) The manual further says: "If a connection state change call back
> function is not installed when ca_create_channel is called (if a 
> nil function pointer is supplied) then the application program 
> must wait for successful status from ca_pend_io prior to using 
> the channel for the first time."
> 
> I have some difficulty infering what "must" and "using" means in this
> case.
> 
> At first, i thought it means that the behavior of CA routines 
> that take a chid as argument is undefined if called with the 
> chid returned from ca_create_channel (with null connection 
> handler) before ca_pend_io returns success. However, this 
> seems to contradict what is said in the description of
> ca_create_channel: "The function ca_state(CHID) can be used to 
> test the connection state of a channel. Valid connections 
> may be isolated from invalid ones with this function if 
> ca_pend_io() times out." This statement suggests
> that at least ca_state seems to have a defined behavior.
> 

I agree that this part of the manual could be improved so I changed it as
follows:

Connection Management

Application programs should assume that CA servers may be restarted, and
that network connectivity is transient. When you create a CA channel its
initial connection state will most commonly be disconnected. If the Process
Variable's server is available the library will immediately initiate the
necessary actions to make a connection with it. Otherwise, the client
library will monitor the state of servers on the network and connect or
reconnect with the process variable's server as it becomes available. After
the channel connects the application program can freely perform IO
operations through the channel, but should expect that the channel might
disconnect at any time due to network connectivity disruptions or server
restarts.

Three methods can be used to determine if a channel is connected: the
application program might call ca_state to obtain the current connection
state, block in ca_pend_io until the channel connects, or install a
connection callback handler when it calls ca_create_channel. The ca_pend_io
approach is best suited to simple command line programs with short runtime
duration, and the connection callback method is best suited to toolkit
components with long runtime duration. Use of ca_state is appropriate only
in programs that prefer to poll for connection state changes instead of
opting for asynchronous notification. The ca_pend_io function blocks only
for channels created specifying a nill connection handler callback function.
The user's connection state change function will be run immediately from
within ca_create_channel if the CA client and CA server are both hosted
within the same address space (within the same process).

> So, what about calls to ca_change_connection_event? 
>(I.e is it possible to circumvent the above mentioned 
> deadlock situation by calling ca_create_channel without 
> connection handler and afterwards call ca_change_connection_event?)

Possibly, but as you discovered there are potential race conditions in
multi-threaded applications. I would need to know more about what you block
for in the connection handler in order to give any further advice about
deadlocks.

Jeff

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System