So I still don't understand the difference between these two code block
examples:
1)
do forever {
<whatever>
ca_pend_io( 5.0 )
delay .1 seconds
}
2)
do forever {
<whatever>
ca_pend_io( 5.0 )
ca_pend_event( 0.1 )
}
Won't the overall behavior be approximately the same? I mean, eventually
there will be stuff for CA to do and won't it get done in a ca_pend_io
call? It seems to me that the 2nd example will get it done perhaps
.1 second before the 1st and not 4 seconds before (like I observe when
processing many, many events).
Sorry for being so obtuse.
John Sinclair
On Mon, 19 Nov 2001, Jeff Hill wrote:
>
> > Is this behavior reasonable? Does pend event do something fundamentally
> > different from pend io?
>
> Yes. If you have not made any of the following IO requests since the last
> call to ca_pend_io() (or the start of the program whichever is first), then
> ca_pend_io() will have no effect other than to flush the output queue,
> and ca_pend_io() will return immediately without blocking for the duration
> of the specified time out.
>
> 1) created a CA channel (without specifying a connection call back handler)
> 2) made a CA get request (without specifying an IO completion call back handler)
>
> In contrast ca_pend_event() will always process CA background activity
> for the full duration of the specified timeout and until all queued
> labor has been processed by CA.
>
> You should call ca_poll() or ca_pend_event(1e-12) in the background at least
> a 10 Hz rate. Alternatively, in EPICS R3.14 if your application is thread safe,
> you can enable preemptive call backs and not bother with polling ca_pend_event().
>
> Jeff
>
> > In the course of testing edm, I have noticed the following behavior for
> > some configurations (unfortunately, I don't mean anything precise when I
> > say "some configurations"):
> >
> > I run a fresh copy of edm, bring up a display containing ~9000
> > references to the same pv and execute it. This adds ~9000 events to the
> > ioc (or portable CAS). Performance is good.
> >
> > I now deactivate the display which clears all the events.
> >
> > From this point on, when this or any other display is executed, the
> > performance is such that it takes twice as long to complete the
> > process of adding all the events.
> >
> >
> >
> > At this point the code looked something like the following:
> >
> > ====================================
> >
> > for all pvs {
> >
> > add events
> >
> > }
> >
> > ca_pend_io( time )
> >
> > ====================================
> >
> >
> >
> > So, I changed this to
> >
> > ====================================
> >
> > count=0
> > for all pvs {
> >
> > add events
> > if ( ++count > someNumber ) {
> > ca_pend_io( time )
> > count=0
> > }
> >
> > }
> >
> > ca_pend_io( time )
> >
> > ====================================
> >
> >
> >
> > This did not help at all. Then I change to code to
> >
> > ====================================
> >
> > count=0
> > for all pvs {
> >
> > add events
> > if ( ++count > someNumber ) {
> > ca_pend_io( time )
> > ca_pend_event( small-time )
> > count=0
> > }
> >
> > }
> >
> > ca_pend_io( time )
> > ca_pend_event( small-time )
> >
> > ====================================
> >
> >
> >
> > This made an amazing difference and now the performance is good all the
> > time.
> >
> > Is this behavior reasonable? Does pend event do something fundamentally
> > different from pend io?
> >
> >
> > John Sinclair
> > [email protected]
> > Oak Ridge National Lab
> > 865-576-6362 865-574-1268 (fax)
> >
>
John Sinclair
[email protected]
Oak Ridge National Lab
865-576-6362 865-574-1268 (fax)
- Replies:
- RE: channel access Jeff Hill
- References:
- RE: channel access Jeff Hill
- Navigate by Date:
- Prev:
RE: channel access Coleman, Thomas A.
- Next:
Re: channel access Andrew Johnson
- 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: channel access Jeff Hill
- Next:
RE: channel access 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
|