g+
g+ Communities
Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014 
<== Date ==> <== Thread ==>

Subject: Re: sysAtReboot
From: Andrew Johnson <anj@aps.anl.gov>
To: "Ernest L. Williams Jr." <ernesto@ornl.gov>
Cc: EPICS tech-talk <tech-talk@aps.anl.gov>
Date: Fri, 07 Jan 2005 10:11:47 -0600
Ernest L. Williams Jr. wrote:

What is sysAtReboot introduced in EPICS R3.14.7?


Below is the message I received from Kay Kasemir when testing:
==================================================================
When loading the IOC application, one of the C++
constructors in EPICS base complains
"sysAtReboot not found. epicsExit will not be called by reboot".

I guess we should have documented this better, which if present is used by the new epicsExit() subsystem in R3.14.7.


I added the following code to the APS vxWorks BSPs:

/* This gives a rebootHook for EPICS before netLib has been shut down,
 * and also runs the C++ static desctructors of all loaded modules */
VOIDFUNCPTR _func_sysRebootHook = NULL;

static int sysRebootHook(int startType) {
    if (_func_sysRebootHook)
        (*_func_sysRebootHook)();
        cplusDtors(0);
    return OK;
}

int sysAtReboot(VOIDFUNCPTR closedown) {
    if (closedown && _func_sysRebootHook) return ERROR;
    _func_sysRebootHook = closedown;
    return OK;
}

The vxWorks reboot hooks are executed in the order in which they are registered, whereas it would make a lot more sense if they were executed in reverse order. WRS have shown no inclination to fix this bug (which they even document as a bug IIRC), so I now register a reboot hook routine *before* netLibInit() gets run (from the same routine where I configure the network memory pool):

rebootHookAdd(sysRebootHook);

By registering a reboot hook routine there, libCom's epicsExit() subsystem can call the routines registered with epicsAtExit() before the vxWorks network gets shut down by its hook routine, and as a result CA circuits close down nicely whenever you do a Control-X reboot. It also calls all the C++ static destructors as well.

It is not strictly necessary to add the above code to your BSPs; EPICS will work exactly as it always has without this, with the exception of the warning message that Kay reported. Having it there does make vxWorks IOCs slightly better network citizens though, and may reduce some delays when the rebooted IOC comes up.

- Andrew
--
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro


Navigate by Date:
Prev: Web service interfaces for EPICS Bill St. Arnaud
Next: Multi-gauge Driver Kiman Ha
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014 
Navigate by Thread:
Prev: RE: Problem building 3.14.7 on win32-x86 Jeff Hill
Next: Multi-gauge Driver Kiman Ha
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICSv4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·