Experimental Physics and
Industrial Control System

Ben Franksen <[email protected]> · Wed, 27 Oct 2010 00:23:54 +0200

Hey Jeff

many thanks for the detailed (and prompt) answers. I am glad that there 
are no artificial restrictions to be observed from the client side. 
Interesting also to know what happens if you overload the server or the 
client library although that is not the scenario I had in mind. I was 
just concerned about 'collisions' when two or more threads occasionally 
access the same channel at (about) the same time.

Some things are still a bit unclear to me:

> > What if I interleave a synchronous ca_get
> > (i.e. I wait for completion using ca_pend or somesuch) with a
> > ca_get or ca_get_callback issued by another thread?
>
> Only a thread which has initialized the library in
> non-preemptive callback mode can call ca_pend_io to
> rendezvous with completion of a batch of no-callback
> gets which have been requested;

I didn't know that. What happens if I do it anyway, i.e. call a regular 
ca_get in preemptive callback mode twice in a row and then (try to) 
wait for the result using ca_pend_io? (Same thread).

> furthermore, it's not 
> allowed to attach additional threads to a non-preemptive
> callback mode ca context.

Yes, I knew that. So let's assume preemptive callback mode.

> So while one can mix ordinary get and callback get in
> a non-preemptive mode ca context, a preemptive mode ca
> context is a no-callback get free zone.

Wait, do I understand this right? How can I get a callback if I do plain 
ca_get? Or did you mean: in preemptive callback mode plain ca_get (no 
callback) is always blocking?

Cheers
ben

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System