Experimental Physics and
Industrial Control System

<[email protected]> · Wed, 14 Sep 2011 09:26:07 +0000

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
> >

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System