Experimental Physics and
Industrial Control System

Well - I'm not really working on this problem. I'm just
a 'user' of the asyn motor driver and I was hoping it
would 'behave the way I'd expect' but it turns out it
doesn't - so I live with some work-arounds...

T.

On 09/14/2011 04:26 AM, [email protected] wrote:

Hi,

I'm fairly interested in this work... As well making asyn motor drivers robust against the problem of missing controllers at boot time, I'd also like to be able to automatically connect to a controller that has been attached, that wasn't present at original boot time. Although, I haven't really looked into this yet.

Cheers,
Matt

-----Original Message-----
From: [email protected] [mailto:tech-talk-
[email protected]] On Behalf Of Till Straumann
Sent: 13 September 2011 19:22
To: Davidsaver, Michael
Cc: EPICS Techtalk
Subject: Re: asynMotorController exception safety

re: zombie - I'm aware of this technique but wanted
to make sure I'm not missing something.

Thanks
-- T.

On 09/13/2011 01:12 PM, Davidsaver, Michael wrote:

-----Original Message-----
From: [email protected] [mailto:tech-talk-
[email protected]] On Behalf Of Mark Rivers
Sent: Tuesday, September 13, 2011 1:27 PM
To: Till Straumann; EPICS Techtalk
Subject: RE: asynMotorController exception safety

...
If your constructor throws an exception, does that automatically

result

in a call to the destructor for the base classes?

Absolutely yes.

If the constructor of an object (or sub-object) completes then its
destructor will be called.  Sub-objects may be base classes, or

member

objects.  This behavior why container classes can effectively manage
resources.

I think the basic problem is that asyn ports can't be unregistered.
When the asynPortDriver instance is destroyed it frees its
asynStandardInterfaces member structure.  This leaves asynManager
holding invalid pointers.

@Till, When I face this situation I set a flag if the constructor

fails

which prevents the port from ever connecting.  Something like:

class myport : asynPortDriver {
    bool zombie;
    ...
}

myport::myport()
    : zombie(false)
{
try {
    // normal initialization
}catch(...){
    zombie=true;
}
}

myport::connect(){
    if(zombie)
      return asynError;
}


A better solution would be to avoid freeing asynStandardInterfaces.

Michael

I would not have
thought so, but I'm not enough of a C++ expert to know the answer to
that.

Mark


-----Original Message-----
From: Till Straumann [mailto:[email protected]]
Sent: Tuesday, September 13, 2011 11:40 AM
To: EPICS Techtalk; Mark Rivers
Subject: asynMotorController exception safety

I wrote a driver class derived from asynMotorController
(which BTW was easy, thanks for the great package).

I would like the driver to be robust in case e.g., of the
absence of e.g., hardware or a serial communication channel.

Hence, my class does something like:

class MyDrv : public asynMotorController {
public:
       MyDrv() : asynMotorController(<parameters go here>)
       {
           status = detect_hardware(<parameters>);
           if ( status ) {
               throw MyException("HW detection failed\n");
           }
       }
};


In my main application I create a driver object


try {
      new MyDrv();
} catch (MyException&e) {
      printf("Unable to create driver: %s\n", e.what());
}

However, if hardware detection fails and the exception
is thrown and subsequently caught then the IOC application
will eventually (later) segfault in asynPortDriver::callbackTask()
(when trying to lock the mutex). It seems that the work
of the superclass constructor(s)
(asynMotorController/asynPortDriver/...) is
not properly undone.

No segfault happens if I comment the entire try block
(including the 'new' statement), i.e., if I create no
driver at all (but still load the .db file etc.).

How am I supposed to handle failure in the constructor?

Thanks
-- Till

References:

asynMotorController exception safety Till Straumann

RE: asynMotorController exception safety Mark Rivers

RE: asynMotorController exception safety Davidsaver, Michael

Re: asynMotorController exception safety Till Straumann

RE: asynMotorController exception safety matthew.pearson

Navigate by Date:

Prev: RE: ioc linux crash using errlogprintf Davidsaver, Michael

Next: Re: Another newbie question - seq record example? Paul Nord

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: asynMotorController exception safety matthew.pearson

Next: Does anyone have VMIC-3123A driver and device support in EPICS 3.14 version? Ma Xiaoyuan

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