Hi Andrew
We have two separate issues here.
(1) The bo record. I was aware of the fact that the bo record does not
remain active during its HIGH time. Maybe I should have explained the
idea behind the test db file a bit more, but I added the test setup as
an afterthought and the mail was already long enough. I am using the bo
record's HIGH field only so that I can see a change in the value with a
camonitor in another window. The actual asynchronous processing is done
by the seq record which has a longer delay for exactly this reason. I
could as well have used a longout for the two "front-end" records and
the result would have surprised me as much.
I am not proposing to change the bo behaviour.
(2) The putNotify behaviour. I admit that I did not read the manual
carefully enough. You cite the ADG:
> 6. In general a set of records may be processed as a result of a
> single dbPutNotify. If a record in the set is found to be active,
> either because PACT is true or because a putNotify already owns the
> record, then that record is not made part of the set of records that
> must complete before the putNotify request completes.
This should have led me to expect the behaviour I see.
> Your second caput is completing immediately because its bo record
> tries to process the OUT link but finds the seq.PACT=TRUE, so it
> gives up and tells putNotify that everything it started has finished.
Agreed, but this is exactly the problem I complained about.
It tells me that an operation successfully completed, when in fact it
did *not* succeed. The bo was supposed to start more than its own
processing, namely processing of the seq record, and this id not
happen. It should be possible to record such a failure and return it to
the requester. Even better, the CA server could detect the failure and
wait until the record in question is no longer busy. It already does so
under certain circumstances, namely if I target the same front-end
record from the same client: in this case the second call waits for the
first fo finish, i.e. the CA server queues the second request.
(Unfortunately I cannot as easily demonstrate this because caput does
not allow to group several asynchronous put operations in one command.)
If I target a different record (even from the same client), this queuing
does not happen. This is inconsistent. I think that the queueing should
ideally always happen for ca_put_callback as long as any record in teh
chain is busy. Failing that, or if the wait times out, at least an
error should be sent back.
Considering the effort that went into the implementation of the
putNotify feature it seems a shame that it cannot be used for what it
was designed, at least not reliably.
Since I don't expect this will be fixed any time soon, I will warn users
of the sequencer that using pvPut(var,SYNC) is inherently unreliable.
Instead completion should be detected by other means, such as reading
back a status bit from the hardware.
Cheers
Ben
- Replies:
- RE: ca_put_callback once again Jeff Hill
- Re: ca_put_callback once again Tim Mooney
- Re: ca_put_callback once again Ben Franksen
- References:
- ca_put_callback once again Ben Franksen
- Re: ca_put_callback once again Andrew Johnson
- Navigate by Date:
- Prev:
Re: ca_put_callback once again Andrew Johnson
- Next:
MAXv issue Dirk Zimoch
- 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:
Re: ca_put_callback once again Andrew Johnson
- 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
|