RE: channel access

[john sinclair <sinclair@mail.phy.ornl.gov>]

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
> > sinclair@mail.phy.ornl.gov
> > Oak Ridge National Lab
> > 865-576-6362   865-574-1268 (fax)
> > 
> 

John Sinclair
sinclair@mail.phy.ornl.gov
Oak Ridge National Lab
865-576-6362   865-574-1268 (fax)