Experimental Physics and
Industrial Control System

"J. Lewis Muir" <[email protected]> · Thu, 06 Nov 2014 22:57:44 -0600

On 11/6/14 5:11 PM, Andrew Johnson wrote:
> The ca_pend_io() routine is never used in this event-driven style
> of programming, where all notifications should be triggered by
> callback events (even channel connections, so your program can respond
> appropriately to disconnection events). The main thread can then
> become a single call to ca_pend_event(0) i.e. wait forever, although
> in practice it's usually more like
>     while (!stop)
>         ca_pend_event(0.1);
>     exit(0);
> to allow the application to set the stop variable and trigger a
> program exit.

Hi, Andrew.

Thank you for your very helpful reply.  I understood everything up
until this last part about calling ca_pend_event.  Why would the main
thread need to call ca_pend_event at all?  For example, I could imagine
it might just wait for an EPICS event indicating it should exit (e.g.
"epicsEventWait(stop_event_id)").

I may be missing something basic here.  In the "Channel Access Reference
Manual" section titled "Polling the CA Client Library From Single
Threaded Applications," it says, "If preemptive call back is not
enabled, then for proper operation CA must periodically be polled to
take care of background activity."  I took that to mean it only applied
in nonpreemptive mode and found no such statement about needing to call
ca_pend_event (or others?) when in preemptive mode.

If ca_pend_event does need to be called in preemptive mode, are there
rules governing how it needs to be called?  Also, are there other CA
functions that could be called instead of ca_pend_event?

Lastly, if there was a main thread like what you suggested, it seems
to me that this could result in inefficient CA network I/O in certain
cases.  For example, say there was a second thread (i.e. not the main
thread) that was making ca_get_callback calls for *lots* of channels.
According to the CA reference manual, the most efficient approach would
be to make all those calls and then call one of ca_flush_io, ca_pend_io,
ca_pend_event, or ca_sg_pend, to forward the accumulated get requests
over the network to the CA server all at once (or at least in as few
"messages" as possible).  If the main thread is calling ca_pend_event
all the time, wouldn't that cause accumulating get requests in the
second thread to be sent over the network prematurely?  Not that that's
wrong, but it might be less efficient, right?

Thank you!

Lewis

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System