Experimental Physics and
Industrial Control System

Matt Newville <[email protected]> · Fri, 4 Nov 2011 09:10:23 -0500

Tim, Jeff, Andrew,

On Thu, Nov 3, 2011 at 4:08 PM, Jeff Hill <[email protected]> wrote:
> Hi Matt,
>
> In a single threaded (non-preemptive callback) client no CA activity can
> occur (i.e. processing network packets and or calling callbacks) unless your
> single thread is executing in the CA library. The ca_pend_event call is
> purely a mechanism for spending some time, the amount of time being
> specified by its sole argument, in the library. The ca_pend_event call is
> not used in any way for synchronizing ca_array_get (or channel
> connectivity).
>
> In contrast, ca_pend_io will synchronize completion of all outstanding
> ca_array_get requests issued since the beginning of the ca context, or the
> previous call to ca_pend_io, whichever is later. In practice, what this
> implies is that ca_pend_io is a one-time synchronization. If it returns
> ECA_TIMEOUT this implies that any incomplete CA get requests are effectively
> canceled. The library will _not_ allow your variable, specified to ca get,
> to be modified unexpectedly far in the future after ca_pend_io returns if
> the network is slow. That could be result in a disaster, for example, if you
> are using a stack automatic variable.
>
>> That is, how do I know how long to wait in ca_pend_event() and
>> ca_pend_io()?
>
> It's actually quite difficult to write a program that is generic in a wide
> range of networking environments if there are any short timeouts which are
> hardcoded. In practice, network generic programs with complex state
> transitions typically use CA callbacks.
>
>> leaves the data at pvalue incorrect (all zeros).  Trying to access
>> this data from python, I can get python to segfault for large enough
>> data (say, 4.2M ints).  I'm not sure I fully understand why python is
>> crashing -- the segfault happens well after ca_array_get() returns,
>> but can happen in ca_pend_event() a short time later.  If I save but
>> don't try to access the data in pvalue, or wait "long enough", it
>> seems I never have a crash.
>
> I suspect that python, or the ca python interface library, isn't happy if
> its data is being modified by an outside thread (i.e. a ca client library
> auxiliary thread) precisely at the same time that its being read. It's
> probably a good idea not to touch the data until ca_pend_io synchronized, or
> alternatively use a callback.
>
>> Is there a way to tell if pend_event() or pend_io() have timed out
>
> They return ECA_TIMEOUT
>
>> or if there are events that are pending?
>
> The ca_pend_io call returns ECA_TIMEOUT if it timed out before all of the
> get requests completed, and otherwise ECA_NORMAL if they did complete. There
> is also a mechanism for determining at any given instant if the ca_client
> library has outstanding labor (network activity) which needs to be dealt
> with. I can provide more details on that if you are interested.
>
> If you need to know precisely which get requests failed out of many then
> it's probably best to use a callback mechanism.
>
> Jeff

Thanks, that's all very helpful -- I think I had a fundamental
misunderstanding of ca_pend_io().

The python crashes are easy enough to avoid if I see that ca_pend_io()
times out, but that still leaves open the possibility of the data not
being properly written and is reacting to a problem (allocating
memory, passing it to ca_array_get(), and then having python garbage
collect it without telling CA  that this memory location has gone
away) that should be avoided.

Using ca_array_get_callback() definitely looks like the right
solution, and works well in an initial test. I'll switch to that
approach.

Thanks,

--Matt

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System