> He said there are no combinations that will fail, but he's wrong about the
> ca_put_callback() that you remember reading about, the operation can (and
> does) fail in some circumstances.
One put callback failure mode is certainly that the server is blocked waiting for a put callback to finish for a very long time (60 seconds), the request eventually times out in the server, and the server returns an error to the client. Others are bad resource identifier, lack of write access, or a bad data type to be completely rigorous.
> However that's not going to be true if there's any
> asynchronous processing involved. In that case the
> putNotify can still be active when the process()
> operation requested by RSRV thread returns, so the
> server can try processing the second ca_put_callback()
> operation but it may be rejected.
I will have to add a small correction to Andrews statement.
If the 2nd put callback is being started by the same client
(the usage case that Ben specifically called out) then the
per-client thread in the server will know that a put callback
is already in progress for that channel and it will certainly
wait for it to complete before starting a new put notify
request even if it is an asynchronous record.
If the 2nd put callback is being started by a different client
I think I recall (disclaimer: I am working form memory and I
didn't write the dbPutNotify code) correctly that the request
is placed on a list of outstanding requests by dbPutNotify and
these outstanding requests (each with their own private put
notify control block) are, each and every one of them, executed in
the order that they were placed in this queue - asynchronous
record processing or not.
So Andrew is correct that a put notify control block will not
allow a 2nd put notify for the _same_ put notify control block
to be started until the fist put notify (for the same control
block) completes, bit the ca server does not allow that situation
to happen.
Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107
Message content: TSPA
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Andrew Johnson
> Sent: Tuesday, October 26, 2010 4:34 PM
> To: [email protected]
> Cc: Ben Franksen
> Subject: Re: Some Channel Access Questions
>
> Hi Ben,
>
> I disagree with Jeff's response to this part of your question:
>
> On Tuesday 26 October 2010 15:17:36 Ben Franksen wrote:
> > combinations which will fail ("sorry, pv is active")? I remember
> > reading some time ago that only one *db*_put_callback can be active at
> > a time on a record (on the IOC), so will interleaving two
> > ca_put_callbacks also fail?
>
> He said there are no combinations that will fail, but he's wrong about the
> ca_put_callback() that you remember reading about, the operation can (and
> does) fail in some circumstances.
>
> The IOC database can only have one putNotify operation active on a
> particular
> record at once. The server side of a ca_put_callback() operation uses the
> IOC's putNotify mechanism to process the record and discover when the
> processing chain has completed, which is when it notifies the client. If
> your
> first ca_put_callback() has not completed when the second one is
> processed, it
> will be rejected. This requires that at least one of the records in the
> processing chain be asynchronous though.
>
> If the processing chain is all synchronous then the record processing all
> takes place in the context of one of the RSRV (CA server) tasks. In this
> case
> the putNotify completion will be called from the recGblFwdLink()
> processing of
> the last record in the chain, but still in the context of the RSRV thread,
> so
> the CA server can't start processing your second ca_put_callback() request
> until the first one has finished and there's no conflict between your two
> ca_put_callback() operations.
>
> However that's not going to be true if there's any asynchronous processing
> involved. In that case the putNotify can still be active when the
> process()
> operation requested by RSRV thread returns, so the server can try
> processing
> the second ca_put_callback() operation but it may be rejected.
>
> Of course if the CA server you're talking to is not an IOC database then
> the
> behaviour you get depends on capabilities of the underlying server tool,
> which
> might perversely object to some other interleaving that the IOC database
> has
> no problems with.
>
> HTH,
>
> - Andrew
> --
> If a man is offered a fact which goes against his instincts, he will
> scrutinize it closely, and unless the evidence is overwhelming, he will
> refuse to believe it. If, on the other hand, he is offered something
> which affords a reason for acting in accordance to his instincts, he
> will accept it even on the slightest evidence. -- Bertrand Russell
- Replies:
- Re: Some Channel Access Questions Tim Mooney
- References:
- Some Channel Access Questions Ben Franksen
- Re: Some Channel Access Questions Andrew Johnson
- Navigate by Date:
- Prev:
RE: Some Channel Access Questions Jeff Hill
- Next:
Re: ChannelArchiver build problem with 3.14.11 on Suse linux Burkhard Kolb
- 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: Some Channel Access Questions Ben Franksen
- Next:
Re: Some Channel Access Questions Tim Mooney
- 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
|