Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Thu, 01 Mar 2007 10:27:48 +0100

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System