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
<2010>
2011
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
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|