Re: ca_sg_put problem with DISP=1

[Dirk Zimoch <dirk.zimoch@psi.ch>]

Hi Andrew,

what I expected was that ca functions return immediately when they fail and that 
they indicate a failure. Thus, if I can't write to a channel, I expected to be 
informed about that as soon as ca knows that the operation can never succeed and 
not only after some timeout.

What I did was this:

ca_sg_create(&sg);
ca_sg_put(sg, ...);
ca_sg_block(sg, timeout);
ca_sg_delete(sg);

When the channel is writable, it blocks until the record has finished 
processing, just as expected.
When the record needs too long for processing, it times out, as expected.
When the channel is disconnected, it returns an error immediately, as expected.
When trying to write to a read-only field (e.g. PACT) it returns an error 
immediately, as expected.
When access security denies writing, it returns an error immediately, as expected.
Only when DISP=1, it times out instead of returning an error immediately, even 
though ca already knows that the operation can never succeed.

I find that strange.

You said, ca_sg functions are not that useful. I thought they are the correct 
way to implement a "caput and wait until processing has completed". Isn't that 
correct? Is there an other way to do that?

Dirk


Andrew Johnson wrote:
> Dirk Zimoch wrote:
>
> > I got a strange effect with ca_sg_put if writing to a record where 
> > DISP=1.
> >
> > The ca_sg_put succeeds (returns ECA_NORMAL) but then,
> > an error message is printed asynchronously:
> >
> > CA.Client.Exception...............................................
> >     Warning: "Channel write request failed"
> >     Context: "op=1, channel=DZ-AO3, type=DBR_invalid, count=0, 
> > ctx="write notify request rejected""
> >     Source File: ../syncGroupWriteNotify.cpp line 98
> >     Current Time: Wed Feb 28 2007 16:40:34.421658000
> > ..................................................................
> >
> > Finally, ca_sg_block times out, long after it was clear to CA that 
> > writing failed.
> > Especially the last point is strange to me. Is this a bug or is it 
> > designed this way?
>
>
> If you look at the documentation for ca_sg_block(), which is at
> http://www.aps.anl.gov/epics/base/R3-14/9-docs/CAref.html#ca_sg_block
> You'll see that it doesn't currently have any return code that means 
> "operation failed". ECA_NORMAL means success so it can't return that, 
> and if the time period you specified hasn't passed yet then ECA_TIMEOUT 
> isn't appropriate.  The other two codes documented are associated with 
> bad arguments, so it must have been designed to work that way.
>
> > If it works as intended, what is the correct way to handle failing 
> > synchronous writes to records with DISP=1 without timing out?
>
>
> What is setting the record's DISP field, and why do you expect any 
> different behaviour than that which you're seeing?  The DISP field is 
> documented in the Record Reference Manual as meaning "disable/ignore all 
> puts to other fields of this record" and CA flags that as a failure. The 
> CA timeout operations don't mean "retry the operations for this time 
> period"; if you want retries you'll have to code them yourself I'm afraid.
>
> I think you may have discovered one reason why the ca_sg_ functions 
> aren't quite as useful as they initially seem, which is probably why 
> they're not used very much.
>
> - Andrew

--
Dr. Dirk Zimoch
Computing and Controls
Paul Scherrer Institut
phone +41 56 310 5182
fax   +41 56 310 4413