EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: ca_put_callback once again
From: Ben Franksen <[email protected]>
To: EPICS Techtalk <[email protected]>
Date: Mon, 22 Nov 2010 01:12:32 +0100
Hi Everyone

I have made more experiments with ca_put_callback and discovered what I 
think is a serious bug.

Imagine a CA client issuing a ca_put_callback and waiting for the 
callback. This might take a while because of asynchronous records being 
processed and waiting for their processing to complete. This processing 
can be caused either directly by the put, or indirectly (via forward or 
PP output links, maybe PP input links too). All this is documented in 
the Developer's Guide under putNotify. So far so good.

Now imagine another ca_put_callback happens, which triggers processing 
of another network of records and this set overlaps with the first one 
above, while the first request is still in progress.

What will happen? My original thought was that this might depend on 
whether the two calls come from the same client or from two different 
clients. This is not the case, however, except in the special case that 
both calls in fact target the same record. In this case, requests from 
the same client will be queued in the server, whereas requests from 
different clients behave as in the general case to which I come now.

If the two calls target different records, but the processing chains (or 
networks) overlap, then what happens is that the second call 
*immediately* gets a *successful* callback.

This is not what I expected. I had assumed that the CA server would send 
back an error to the second client, saying that there is already 
another request pending. Indeed, there is an error code in caerr.h, 
namely

#define ECA_PUTCBINPROG     DEFMSG(CA_K_ERROR,     45)

that I assumed is there for this case. Not so.

The problem is that this defeats the whole purpose of the 
ca_put_callback resp. putNotify which is to make sure that the 
processing really has completed. If another client, *any* client 
anywhere on the control network happens to issue a call that interferes 
with mine it might be that I get a success callback even though nothing 
has completed yet.

This is a bug, IMO. If a client specifically asks for a callback to make 
sure something it wishes to happen in the server has actually happened, 
then the server must either wait for completion, however long it takes, 
or else respond with an error.

BTW, the scenario can be easily tested, this is my test db file (which I 
run with 'softIoc -d <dbfile>'):

record(bo,"pvPutAsync1") {
    field(ZNAM,"Low")
    field(ONAM,"High")
    field(HIGH,"1")
    field(OUT,"pvPutAsyncSeq.SELN PP")
}
record(bo,"pvPutAsync2") {
    field(ZNAM,"Low")
    field(ONAM,"High")
    field(HIGH,"1")
    field(OUT,"pvPutAsyncSeq.SELN PP")
}
record(seq,"pvPutAsyncSeq") {
    field(SELM,"Specified")
    field(DLY1,"2")
    field(DOL1,"1")
    field(LNK1,"pvPutAsyncRes CA")
}
record(longin,"pvPutAsyncRes") {
}

This is the test command line and the output:

ben@sarun[3]: .../seq/work > time caput -c -w5 pvPutAsync1 1 &; sleep 1; 
time caput -c -w5 pvPutAsync2 1
[1] 32140
Old : pvPutAsync1                    Low
Old : pvPutAsync2                    Low
New : pvPutAsync2                    High
caput -c -w5 pvPutAsync2 1  0,00s user 0,01s system 22% cpu 0,036 total
New : pvPutAsync1                    Low
caput -c -w5 pvPutAsync1 1  0,00s user 0,00s system 0% cpu 2,034 total
[1]  + done       time caput -c -w5 pvPutAsync1 1

I checked the code in caput.c to make sure that caput reports an error 
in the callback message. It does and as you can see there is no error 
reported. The test was run under 3.14.12-rc1 for the client (the -c 
switch is new), but tests with the sequencer indicate that it happens 
in 3.14.8.2, too.

Cheers
Ben
-- 
"Never confuse what is natural with what is habitual."
                                   -- attributed to Mahatma Gandhi

Replies:
RE: ca_put_callback once again Jeff Hill
Re: ca_put_callback once again Andrew Johnson

Navigate by Date:
Prev: Re: Cross-compilation missing library emmanuel_mayssat
Next: RE: ca_put_callback once again Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: ChannelFinder Web Service 1.0.0 (beta) released Ralph Lange
Next: RE: ca_put_callback once again Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  <20102011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 22 Nov 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·