> >> It sure would be nice to have an option in the sequencer that would
> >> use ca_put_callback() ... i.e. a call that wouldn't return until
> >> record processing caused by the 'put' was complete. I'm trying to work
> >> with a device that is quite unpredictable in its response time.
> >
> >It would also be nice to get a 'done' event corresponding to a 'put'
> >without hanging at the 'put' call.
>
> I agree with both suggestions. ca_put_callback() really should be supported
> and you really shouldn't have to block until the callback has been delivered.
>
> Off the top of my head, how about the following spec:
>
> pvPut( var ); /* existing behavior */
>
> pvPut( var, wait ); /* use ca_put_callback(); if wait==TRUE, block on
> completion with some pre-determined timeout */
>
> pvPut( var, wait, timeout );
> /* as above but specify the timeout */
>
> if wait==FALSE, pvPut() will not block and completion can be checked by using
>
> when ( pvPutDone( var ) ) {
> }
>
> which will fail if no put is active, or wait for put completion otherwise.
> Timeouts can be handled using the normal delay() mechanism. There would
> probably also need to be a pvPutActive( var ) enquiry function.
>
> I can't make any statement about when this might get done (assuming that
> no-one gets there before I do). I would prefer to make this change only to
> the still-unleased version that has the PV queueing facilities. We have been
> using this operationally for several years.
>
> Comments?
1) I agree you should combine this with your PV-queue capable version.
2) Above calling sequences are OK, however, I think I prefer
pvPut( var )
pvPutCallback( var, wait, timeout )
pvPutDone( var )
a) I prefer to stick with a fixed number of arguments for given calling name
rather than C++-style "different args is different semantics".
b) I think timeout should be specified--what would a "good" values
be for timeout?
c) presumably if you choose wait==FALSE and later call pvPutDone(), when
the original timeout expires it also fails, but with E_TIMED_OUT
instead of E_NOT_WAITING. And if it has succeeded already it returns
OK, just as it does for normal unblocking?
--Steve
- Navigate by Date:
- Prev:
RE: Epics build for Multiple Host Architectures? Mark Rivers
- Next:
Re: Frame grabber and Portable channel access Brian Tieman
- 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: SNL request William Lupton
- Next:
Re: SNL request William Lupton
- 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
|