Re: More CA questions

[Benjamin Franksen <benjamin.franksen@bessy.de>]

Hello Jeff,

first, thanks for the detailed answers.

On Tuesday 16 March 2004 20:46, Jeff Hill wrote:
>
> If it isn't possible to easily rearrange your code to circumvent these
> difficulties then please send another email describing the situation in
> more detail. If the current situation is causing an unavoidable hassle then
> I will need to consider alternatives.

thanks for the ofefr, but as i wrote in my follow-up message, i already found 
a nice way to circumvent this problem with almost zero overhead. The idea is 
that the connection handler only needs to check wether the information is 
already in place and if not provide it *by itself*. What i didn't realize at 
first is that it can easily do so: it gets the properly initialized chid as 
an argument and therefore is in exactly the same position as the routine that 
called ca_create_channel when the chid is returned. So i try to initialize 
the object in question (the thing i wanted to wait for in the handler) at 
both places -- after ca_create_channel returns and as first action inside the 
handler -- and whoever is first wins. It's completely symmetrical (and works 
fine).

> > Is this also the case if CA is used multi-threaded, i.e.
> > initialized with the ca_enable_preemptive_callback flag?
>
> Yes, the behavior does not change if preemptive callback is enabled.

OK, i thought so; just wanted to be sure.

> > (2) Does a similar rule apply to ca_change_connection_event if
> > previously ca_create_channel was called with a NULL connection handler?
>
> The ca_change_connection_event() installs the new connection handler
> function pointer, but does not cause the function to be invoked. That
> occurs only when the connection state of the channel changes.

Ok.

> > Btw, ca_change_connection_event is nowhere mentioned in the new CA
> > client reference. I hope it was just forgotten and is not deprecated.
>
> As you have discovered, use of ca_change_connection_event() in
> multi-threaded applications can be problematic, and IMHO its not a high
> quality interface in single threaded situations either. Therefore, future
> use of this interface is being discouraged.

I see. If an actual *change* in the connection handler is required, this can 
of course be done with a 'master' handler that calls a different routine for 
doing the actual work.

However, without ca_change_connection_event the choice of notification method 
if irrevocable: It cannot be changed once ca_create_channel has been called. 
so maybe it is better to keep suporting this routine, if only so that the 
application can change its mind about wether to wait explicitly inside 
ca_pend_io or to be notified via callback. (Though, actually, i can't think 
of an application where having this possibility is of any importance... and 
one can always close the channel and reopen it with or without a handler. So 
maybe it *is* ok to deprecate it.)

> > ...I have some difficulty infering what "must" and "using" means in this
> > case...
>
> I agree that this part of the manual could be improved so I changed it as
> follows:
> 
> Connection Management
>
> [...]

So, my latest assumption (that behavior of routines is defined but channel 
status might be disconnected) was correct. Good. The text also answers a 
question i didn't raise yet, but already had in my mind, namely, if the 
connection state may also be polled using ca_state.

Thanks again and keep up the good work.

Cheers,
Ben

PS: I just stumbled over the next issue that gives me headaches, namely that 
the default for application threads is to always create a separate client 
context, instead of joining an existing one. It would be *very* nice if this 
default behavior could be overridden somehow, maybe via some compile time 
switch (like -DCA_DEFAULT_SHARE_CONTEXT) or some global configuration call or 
whatever. Likewise, it would be nice if one could override the default flag 
that is given to ca_create_context whenever it is called implicity, i.e. 
change the default to ca_enable_preemptive_callbacks. At the moment i cannot 
say exactly how critical these two issues are for me, since i am still 
experimenting.