RE: Synchronising CA shut down

["Hill, Jeffrey O" <johill@lanl.gov>]

> 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