| 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 | Index | 2002 2003 2004 <2005> 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: epicsAtExit |
| From: | Andrew Johnson <[email protected]> |
| To: | Marty Kraimer <[email protected]> |
| Cc: | [email protected] |
| Date: | Wed, 16 Nov 2005 15:07:25 -0600 |
Marty Kraimer wrote:
So why did we invent epicsAtExit? Does anyone remember?
I think it was to try and ensure that vxWorks IOCs shut down "nicely" when rebooted with a Ctrl-X. The CA server gets a chance to close all its sockets, thus the clients are immediately notified that the IOC is going down. Without it, the clients don't find out until up to 35 seeconds later that the IOC is no longer there. Where an OS such as Linux carries on running after a soft IOC shuts down it immediately closes all of the CA server's TCP sockets as part of the process tidy-up, so this problem doesn't appear on soft IOCs.
If a vxWorks IOC reboots up before a client even notices that it ever went down, there could also be extra complications before it reconnects, since the client's network stack just thinks that the TCP socket was congested for a while but is still live; the network stack in the restarted server will receive packets intended for the old socket and will have to reject them. I don't know if there are any additional timeouts that this might introduce.
I think there may also have been issues with shutdown on WIN32 systems, the atExit() routines were being run after some DLLs had been unloaded or something like that. I may be totally wrong about this though.
- Andrew -- * * Matt Santos / / Leo McGarry * * For a Brighter America * *