Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: RE: Synchronising CA shut down
From: "Hill, Jeffrey O" <johill@lanl.gov>
To: "michael.abbott@diamond.ac.uk" <michael.abbott@diamond.ac.uk>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Fri, 16 Mar 2012 15:17:53 +0000
> my very rare blips (not exactly crashes, but looks like
> callback in bad context) on shutdown are something else...

It definitely shouldn't be calling your subscription callback after its subscription is destroyed, by design. If you see evidence that it is, that should be considered to be a bug, and I will need to look into it.

> On a related question: can you advise precisely when I need to call
> ca_flush_io()?  I've taken to scattering them through my code recently,
> and I think it's time to get rid of the surplus ones!  I'm currently call
> ca_flush_io() after:
> 
> 1. ca_create_channel
> 2. ca_clear_subscription
> 3. ca_create_subscription
> 4. ca_array_get_callback
> 5. ca_array_put_callback
> 6. ca_array_put
> 7. ca_context_destroy
> 
> I'm guessing that (7) is completely bogus (and even possibly dangerous)
> and from what you've just said (2) is pointless.
> 

Typically, ca requests (for example 2 through 6 above) only enqueue a message for delivery to the server, but do not actually flush the requests out to the network until you request, or until the internal buffering quotas are exceeded in the library. This gives the application code some opportunity to optimize performance by combining its requests. One can optimize throughput by better utilizing (i.e. more completely filling) the buffers in the IP kernel and or the Ethernet frames etc.

The ca_create_channel call is different in that the CA client library will always continuously attempt in the background to move disconnected channels into a connected state. UDP search message aggregation is handled by an array of search request timers with each timer (i) having a delay twice that of timer (i-1). When a search request fails in timer (i) it is moved to timer(i+1). However, note that in non-preemptive mode (single threaded application codes) not everything runs autonomously in the background; you will not receive a connection callback until your application code is executing within the client library.

The ca_context_destroy does send multiple cleanup messages to the server(s), but these messages are implicitly flushed out when the socket for the tcp circuit is closed.

Jeff




References:
Synchronising CA shut down michael.abbott
RE: Synchronising CA shut down Hill, Jeffrey O
RE: Synchronising CA shut down michael.abbott

Navigate by Date:
Prev: Re: Invitation to test cothread.catools release candidate Matt Newville
Next: RE: MVME2434-1 GOURNAY Jean-Francois
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: RE: Synchronising CA shut down michael.abbott
Next: ENV Variables in EDM Szalata, Zenon M.
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·