On 10/09/2016 06:16 PM, Mark Rivers wrote:
> Hi Michael,
>
> Thanks for the quick response.
>
> I have another newbie question.
>
> My class has
>
> private:
> std::string m_pvName;
> std::string m_request;
> short m_priority;
> ChannelProviderPtr m_provider;
> ChannelPtr m_channel;
>
> How do I initialize m_channel in my constructor so that I know that
>
> m_channel = m_provider->createChannel(m_pvName, m_thisPtr, m_priority);
>
> has not yet been call, so I should not call m_channel->destroy()? If this were a normal pointer I would initialize it to 0 and test that, but that does not work for a ChannelPtr.
>
> If I unconditionally call m->channel->destroy() before m_channel has been created the first time I get an access violation.
You should do just what you would with a plain pointer in the ctor. The
difference is that instead of initializing with 'm_channel(0)', just do
'm_channel()'. The default ctor for shared_ptr initializes to NULL.
then for cleanup:
> if(m->channel) m->channel->destroy()
An important note is that shared_ptr does *not* protect you from races
when changing the pointer. So what I would do is the following with a
mutex which guards 'm_channel', but isn't held for destory() or the
dtor, which avoid even the possibility of lock order bugs.
> {
> ...
> ChannelPtr temp; // aka. shared_ptr<Channel>
> {
> Guard G(somemutex); // aka. epicsGuard<epicsMutex>
> temp.swap(m_channel);
> }
> if(temp) temp->destory();
> ...
> // temp goes out of scope and Channel dtor runs
> }
>
> Thanks,
> Mark
>
> ________________________________________
> From: Michael Davidsaver [[email protected]]
> Sent: Sunday, October 09, 2016 1:37 PM
> To: Mark Rivers; EPICS Tech-Talk
> Subject: Re: EPICS V4 question
>
> Mark,
>
> First, the *Requester classes are somewhat "transient", so it's probably
> not a good idea to combine this with ADDriver, which isn't. You may
> also get into trouble should you wish to have one ADDriver associated
> with more than on PVA channel (as you have inadvertently done).
>
> Disconnecting is done with Channel::destory(), not the ChannelRequester.
> For various annoying reasons it is *not* sufficient to let a connected
> Channel be destroyed (as in c++ destructor). Calling Channel::destory()
> is mandatory.
>
> You may (or not) find the following test code useful in understanding
> the Channel/Monitor lifecycle.
>
> https://github.com/mdavidsaver/pva2pva/blob/master/testApp/testtest.cpp
>
> Michael
>
>
> On 10/09/2016 01:24 PM, Mark Rivers wrote:
>> I have some EPICS V4 client code that basically does the following:
>>
>>
>>
>> class epicsShareClass pvaDriver : public ADDriver,
>>
>> public virtual epics::pvAccess::ChannelRequester,
>>
>> public virtual epics::pvData::MonitorRequester
>>
>>
>>
>> …
>>
>>
>>
>> try
>>
>> {
>>
>> ClientFactory::start();
>>
>> m_provider = getChannelProviderRegistry()->getProvider("pva");
>>
>> m_channel = m_provider->createChannel(m_pvName, m_thisPtr,
>> m_priority);
>>
>> m_pvRequest = CreateRequest::create()->createRequest(m_request);
>>
>> m_monitor = m_channel->createMonitor(m_thisPtr, m_pvRequest);
>>
>> }
>>
>> catch (exception &ex)
>>
>> {
>>
>> …
>>
>> }
>>
>>
>>
>> The monitorConnect() and monitorEvent() methods are being called as
>> expected, and everything is working.
>>
>>
>>
>> Now I want to extend the code to allow the current channel to be
>> disconnected, and call m_provider->createChannel() to a different
>> channel. What do I need to do for this? I found that if I just call
>> m_provider->createChannel with a different p_pvName it does not throw an
>> exception, but it appears to simply stay connected to the existing channel.
>>
>>
>>
>> Thanks,
>>
>> Mark
>>
>>
>>
>
- Replies:
- RE: EPICS V4 question Mark Rivers
- References:
- EPICS V4 question Mark Rivers
- Re: EPICS V4 question Michael Davidsaver
- RE: EPICS V4 question Mark Rivers
- Navigate by Date:
- Prev:
RE: EPICS V4 question Mark Rivers
- Next:
RE: EPICS V4 question Mark Rivers
- 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: EPICS V4 question Mark Rivers
- Next:
RE: EPICS V4 question Mark Rivers
- 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
|