> Program of next layer creates detector1, detector2 and system1
> objects.
> The layer is interested in data concerning to detectors and
> systems. It wouldn't like to know anything concerning CA.
>
The typical solution for this sort of problem would be to define
a pure virtual interface class for the entity supplying detector
data. This interface need not have any CA specific details in it.
This interface is passed to the constructor for the detector
objects.
The high level code would call a static factory method in the
detector class to obtain a reference to the virtual interface for
the entity supplying detector data. The static factory method in
the detector might instantiates a CA specific implementation of
the interface, and this interface could be passed to the detector
class constructor.
PS: A C++ based version of the CA client library interface is in
the works and it will definitely directly support this type of
abstraction.
Jeff
> -----Original Message-----
> From: Liyu, Andrei [mailto:[email protected]]
> Sent: Thursday, April 14, 2005 7:21 AM
> To: Jeff Hill; [email protected]
> Subject: RE: CA; ca_context_destoy and CA channels
>
> Just example with some libraries.
> Someone needs play with detector1, detector2, system4. He
> writes
> something like
>
> class CDetector1{
> chid * pSCAIDParameter1;
> evid * pSCAMonitorParameter1;
> ...
>
> public:
> CDetector1();
> ~CDetector1();
>
> void vFDataProcessing(...);//work with detector
> void vFGetData(...);//next layer get data
> }
> class CDetector2{){...}
> class CSystem1{){...}
>
> Program of next layer creates detector1, detector2 and system1
> objects.
> The layer is interested in data concerning to detectors and
> systems. It
> wouldn't like to know anything concerning CA.
>
> Have a good day, Andrei.
>
>
> -----Original Message-----
> From: Jeff Hill [mailto:[email protected]]
> Sent: Wednesday, April 13, 2005 6:29 PM
> To: Liyu, Andrei; [email protected]
> Subject: RE: CA; ca_context_destoy and CA channels
>
>
> > So I open first thread, create CA context, create first
> CA
> > channel. Then I open second thread, attach to current CA
> > context, create second CA channel. ... Then I decide to
> > close first CA channel and close context (???!!!). What
> > is behavior CA library? I suppose second CA channel will
> > be closed without normal procedure of closing
> > second channel + its monitor?
>
> The 2nd channel's subscription (monitor) is removed from the
> IOC,
> the channel is removed from the IOC, the circuit to the IOC is
> disconnected, and the channel is attached to a NOOP CA service.
>
> > But I don't like to close second channel and CA context!
> > Then I should check is that channel latest (is the
> > last channel)? I couldn't find suitable function in CA
> > function API.
>
> There isn't, currently, an interface for this information in
> the
> library.
>
> > I have once way - hold tracks of my CA channels (minimum
> > is global counter). Usually it could be done. But if program
> > is mixture of different libraries and each library comes to
> > CA library then it becomes impossible.
>
> No such interfaces (for attaching and incrementing an in use
> count and detaching and decrementing an in use count) currently
> exist. I will add your ideas to Mantis entry 161 (initiated on
> behalf of Ben) for further consideration.
>
> > But if program is mixture of different libraries and
> > each library comes to CA library then it becomes impossible.
>
> One would need to carefully consider if these independent
> libraries should share a CA context. If so, perhaps you might
> pass a CA context identifier to these libraries when they
> initialize.
>
> Jeff
>
> > -----Original Message-----
> > From: Liyu, Andrei [mailto:[email protected]]
> > Sent: Monday, April 11, 2005 8:57 AM
> > To: [email protected]
> > Subject: CA; ca_context_destoy and CA channels
> >
> >
> > Jeff,
> >
> > If I am not mistaken there are not couple features in
> > current CA
> > function interface.
> > I can suppose that when you came to multithread CA you
> > added
> > get_current_context and attach functions. But there is not
> > similar
> > mechanism for ca_context_destoy.
> > So I open first thread, create CA context, create first
> CA
> > channel. Then I open second thread, attach to current CA
> > context, create
> > second CA channel. ... Then I decide to close first CA
> channel
> > and
> > close context (???!!!). What is behavior CA library? I
> suppose
> > second CA
> > channel will be closed without normal procedure of closing
> > second
> > channel + its monitor?
> > But I don't like to close second channel and CA context!
> > Then I
> > should check is that channel latest? I couldn't find suitable
> > function
> > in CA function API. Maybe get_current_context has something.
> > But it is
> > very deep.
> > I have once way - hold tracks of my CA channels (minimum
> > is
> > global counter). Usually it could be done. But if program is
> > mixture of
> > different libraries and each library comes to CA library then
> > it becomes
> > impossible.
> >
> > Thanks,
> > Andrei.
- References:
- RE: CA; ca_context_destoy and CA channels Liyu, Andrei
- Navigate by Date:
- Prev:
RE: Possible bug in taskwd Jeff Hill
- Next:
Job opening: APS Beamline Controls group leader 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
- Navigate by Thread:
- Prev:
RE: CA; ca_context_destoy and CA channels Liyu, Andrei
- Next:
EPICS Web Server Problems Ralph Lange
- 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
|