Hi Ben,
> (1) The sequencer currently employs an "auxiliary task" which performs
> no work other than calling
>
> ca_pend_event(10.0)
>
> in an endless loop. Note that the context is created with
> ca_enable_preemptive_callback.
>
> I would be glad if I could get rid of this extra task, as I believe it
> is not necessary, but before I throw it out I'd rather make sure that
> there are no unwanted side-effects. Could such a task perhaps improve
> latency in certain situations? A comment in the code says this allows
> for connect/disconnect event processing, and it gets started with a
> slightly higher priority than the regular sequencer tasks. It is quite
> possible that the comment is out-dated, or just plain wrong.
Before R3.14 the ca client library used select to schedule everything so the
sequencer was required to call ca_pend_event periodically; this caused the
callbacks to be called and also took care of background activity such as
sending search requests and timing out unresponsive circuits. In R3.14 if
preemptive callback mode is enabled then there is no need to call
ca_pend_event periodically. In R3.14 the internal design of the library has
everything orchestrated by library private auxiliary threads.
One reason why the sequencer might have preserved the ca_poll
(ca_pend_event) polling might have been to make one code base support both
R3.14 and R3.13, but one could easily add an ifdef to enable spawning a
polling thread only if its R3.13; they will of course need to compile two
different object code versions if they will have support for both R3.13 and
R3.14 at the same site.
BTW, adding reasonable multithreading support to the R3.14 ca client library
slowed the first release some, and some have complained about this, but I
think it was the right thing to do at the time as many applications on the
client side have moved to multithreaded implementations since then.
> (2) If I create a context (with ca_enable_preemptive_callback) in one
> task, then attach to this context in another task, then delete the
> first task without destroying the context. Does the second one continue
> to work with the same context? In other words, is the task that created
> the context in any way "privileged" over tasks that merely attach to an
> existing context? I think not, but I want to be sure.
I don?t recall ever testing that usage scenario, but I believe that it will
work. Internally, the api functions find the context two ways; if a channel
identifier is passed this provides the link to the context, and otherwise
the context is located using a thread private variable. Thread private
variables are of course generally agnostic about which thread might be using
them. There also isn't any feature in the library which auto-magically
destroys a ca client context when the last thread using it goes away. So
this should work just fine - even if one isn't particularly careful about
thread creation order.
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: Ben Franksen [mailto:[email protected]]
> Sent: Sunday, November 14, 2010 2:47 PM
> To: Jeff Hill
> Cc: [email protected]
> Subject: Two CA client questions
>
> Hi Jeff
>
> I have two technical CA (client) questions.
>
> (1) The sequencer currently employs an "auxiliary task" which performs
> no work other than calling
>
> ca_pend_event(10.0)
>
> in an endless loop. Note that the context is created with
> ca_enable_preemptive_callback.
>
> I would be glad if I could get rid of this extra task, as I believe it
> is not necessary, but before I throw it out I'd rather make sure that
> there are no unwanted side-effects. Could such a task perhaps improve
> latency in certain situations? A comment in the code says this allows
> for connect/disconnect event processing, and it gets started with a
> slightly higher priority than the regular sequencer tasks. It is quite
> possible that the comment is out-dated, or just plain wrong.
>
> (2) If I create a context (with ca_enable_preemptive_callback) in one
> task, then attach to this context in another task, then delete the
> first task without destroying the context. Does the second one continue
> to work with the same context? In other words, is the task that created
> the context in any way "privileged" over tasks that merely attach to an
> existing context? I think not, but I want to be sure.
>
> Cheers
> Ben
> --
> "Never confuse what is natural with what is habitual."
> -- attributed to Mahatma Gandhi
- Replies:
- Re: Two CA client questions Ben Franksen
- References:
- Two CA client questions Ben Franksen
- Navigate by Date:
- Prev:
Two CA client questions Ben Franksen
- Next:
Re: Two CA client questions Ben Franksen
- Index:
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:
Two CA client questions Ben Franksen
- Next:
Re: Two CA client questions Ben Franksen
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
<2010>
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|