Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Fri, 7 Nov 2014 17:15:27 -0600

On 11/07/2014 04:35 PM, J. Lewis Muir wrote:
> Is it quite acceptable to *never* call ca_flush_io, ca_pend_io,
> ca_pend_event, nor ca_poll from a CA client using a preemptive mode CA
> context?
> 
> I'm asking to try to untangle what is required and necessary for
> preemptive vs. nonpreemptive mode.  It seems to me that a channel can be
> created with a connection state change callback, and ca_get_callback can
> be used instead of ca_get (and similarly for other functions).  In this
> way, a preemptive-mode CA client could work correctly and never call
> ca_flush_io, ca_pend_io, ca_pend_event, nor ca_poll.  True?

A client that never calls ca_flush_io() may never have its requests sent
out (and hence responded to) if it stops making further calls to the
library that result in additional packets being queued for output. The
http://www.aps.anl.gov/epics/base/R3-14/12-docs/CAref.html#Flushing and
Blocking section of the manual makes that clear.

You might not notice a missing flush operation immediately in clients
that connect to lots of channels because the later search requests would
push out the earlier ones and then the subscription and I/O operations
would start, resulting in enough traffic to keep things flowing,
although the network might appear sluggish and you might experience 30
second freezes if/when traffic slows down enough.

The other routines you can safely omit from a preemptive client program
as you described.

- Andrew
-- 
People everywhere confuse what they read in newspapers with news.
-- A. J. Liebling

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System