following up to myself: The issue goes down a bit deeper, and it's about the notion of controlled shutdown
This is a dark corner of LinuxCNC, especially with respect to time-to-estop for connected hardware, and it warrants some thought and work. Unfortunately I dont have a quick answer for you, but let me sketch it out: - either HAL or RTAPI's session concept needs to be firmed up, this is a very loosely defined area as of now - what is lacking is a defined sequence of operations which happens at shutdown (for whatever reason that would be); that needs to work reliably regardless of the underlying RT infrastructure (read: _lots_ of testing, and automated please; very likely external hardware is needed to verify results) I have looked into the issue in the past, more with an eye towards fast estop, and the gist was: if it is too work fast, the shutdown sequence must be aware of the hardware it is using; for instance, the fastest, lowest-impact method to shutdown a Mesa card was to remove the watchdog function from the thread which got the time windows down to a watchdog period. So shutdown is fast or portable, tick either one. It is not an issue which can be solved en passant with a quick fix; it needs a bit of a plan and some systematic work which doesnt immediately yield results. I know this doesnt yet help you at the application level yet and part of the issue with gladevcp and signals is that it is, well, a signal, which always has been a touchy vehicle for critical sequences. In case the on_unix_signal method turns out to be insufficiently reliable, what could help in the gladevcp case is to adapt signal handling like so: - use a signal file descriptor (signalfd) - watch the signal file descriptor in the gladevcp main loop and associate an event handler with it - this will deliver a signal in-line with other gtk events to the Python code, and in a controlled order, hopefully making it more reliable I know the above is technobabble - in the faint hope somebody other than me picks up the work It is needed though I think - gladevcp use is mutating from a widget add-on to a primary UI vehicle. - Michael Am 03.03.2013 um 08:06 schrieb Michael Haberler: > > Am 03.03.2013 um 03:46 schrieb Kip Shaffer: > >> Anybody using GladeVCP with Persistence? Did you have trouble getting >> it to save settings? >> ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
