Re: [Emc-users] GladeVCP Persistence On_Destroy sensitivity
On Mon, Mar 4, 2013 at 4:20 AM, Michael Haberler wrote:
>
> > So when a user selects File->Quit, a SIGTERM should be generated?
>
> You mean in Axis? In a gladevcp application?
>
> please share a bit more more detail about your setup - depending on the
> answer, different things happen, which is probably part of your problem:
>
> - if Axis is exited, the linuxcnc script notices and starts sending a
> SIGTERM and eventuall SIGKILL to all running process, so yes, gladevcp
> should receive a SIGTERM and that can be handled
>
Apologies, I should should have described my setup a bit more. I _am_
talking about a GladeVCP panel embedded in Axis, and from the previous
discussion, I was hoping SIGTERM would have triggered my on_unix_signal()
in the same way that pressing Control-C does. It may be that there are
other issues that prevent it from responding appropriately.
It would help if we could isolate the issue a bit more, namely a) are those
> signals generated b) how are they reacted to
>
> habe a look at the gladevcp source code to see how the signal handlers are
> installed, you can do that 'custom' easily:
>
> if handlers.has_key(signal_func):
> dbg("Register callback '%s' for SIGINT and SIGTERM" %(signal_func))
> signal.signal(signal.SIGTERM, handlers[signal_func])
> signal.signal(signal.SIGINT, handlers[signal_func])
>
> I will trace through the source and look for this section. I'll follow
the execution to see where it's failing.
> > I think for now, I am going to regard auto-saving widget states as
> > unreliable. Instead, I will keep anything that ought to be saved in
> > vars, which don't disappear on me.
>
> hey, lets apply a bit more rigor here. This _must_ work reliably
> eventually, period.
>
> Please help with it.
>
I will happily help with it. Part of the miracle that is open-source
software is the result of the collaborations that occur. This philosophy
resonates deeply with me.
I was simply responding to your earlier comments that coming up with a
robust solution must be done carefully and deliberately. I wanted you to
know that in my particular situation, namely saving 1 or 2 variables, is
not being delayed by any of the issues we have discussed, so my problem is
solved.
I am not a software engineer, barely know any Python, and first looked at
Glade about 15 days ago. But I might question the strategy of storing
information in volatile objects like widgets. In the Model-View-Controller
architecture, there is a distinct separation between Data (Model) and
View/Controller. The GladeVCP.persistence vars have this separation,
whereas the data stored in the widgets do not. Since there are many ways
for widgets to be destroyed, IMHO the likelihood that we can intercept
their destruction 100% of the time seems low. Thus storing any persistent
information in a less volatile location is attractive.
Maybe we could expose functionality to the users to update the data model
directly:
def on_change:
self.ini.setvalue(objectname, objectvalue)
-Kip
--
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
Re: [Emc-users] GladeVCP Persistence On_Destroy sensitivity
Kip,
Am 04.03.2013 um 02:18 schrieb Kip Shaffer:
> So when a user selects File->Quit, a SIGTERM should be generated?
You mean in Axis? In a gladevcp application?
please share a bit more more detail about your setup - depending on the answer,
different things happen, which is probably part of your problem:
- if Axis is exited, the linuxcnc script notices and starts sending a SIGTERM
and eventuall SIGKILL to all running process, so yes, gladevcp should receive a
SIGTERM and that can be handled
- if you have a File->Quit button in gladevcp, I dont know what handler is
connected to that event, but if it triggers a Gtk shutdown, that can be trapped
early to save state
> It
> doesn't trigger the on_unix_signal(), whereas hitting Control-C does.
It would help if we could isolate the issue a bit more, namely a) are those
signals generated b) how are they reacted to
habe a look at the gladevcp source code to see how the signal handlers are
installed, you can do that 'custom' easily:
if handlers.has_key(signal_func):
dbg("Register callback '%s' for SIGINT and SIGTERM" %(signal_func))
signal.signal(signal.SIGTERM, handlers[signal_func])
signal.signal(signal.SIGINT, handlers[signal_func])
Maybe all we need to add is SIGKILL to this list.
> I think for now, I am going to regard auto-saving widget states as
> unreliable. Instead, I will keep anything that ought to be saved in
> vars, which don't disappear on me.
hey, lets apply a bit more rigor here. This _must_ work reliably eventually,
period.
Please help with it.
- Michael
>
>
> On 3/3/13, Michael Haberler wrote:
>>
>> Am 03.03.2013 um 13:45 schrieb andy pugh:
>>
>>> On 3 March 2013 07:39, Michael Haberler wrote:
>>>
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.
>>>
>>> This is considering the process that happens when LinuxCNC is exited
>>> with a machine powered-up and running? I can see this is a type of
>>> e-stop, but not the normal sort.
>>
>> Right
>>
>>> Is it possible to refuse to quit until at least one servo cycle has
>>> run with the LinuxCNC enable outputs disabled?
>>
>> the current sequence is in scripts/linuxcnc function Cleanup:
>>
>> it sends signals to all user processes (UI, task etc) ; first SIGTERM, later
>> SIGKILL if a process wont exit
>> then it stops the realtime threads via halcmd stop
>> then it proceeds to unload hal_lib, rtapi and modules and cleans up
>>
>> If anything happens before threads are stopped really depends on what user
>> processes are doing and if/how they react to a signal
>>
>> what I was referring to: if you react to the shutdown signal (or a segfault
>> for that matter) in one of the user processes, that potentially reduces the
>> time window until threads are stopped, and there is some choice what still
>> can be done - provided safe signal programming techniques are used
>>
>> I'd need to look if any components actually react in HAL due to a signal
>> directly; cant remember having seen it
>>
>> -m
>>
>>
>> --
>> 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
>>
>
> --
> 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
--
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
Re: [Emc-users] GladeVCP Persistence On_Destroy sensitivity
So when a user selects File->Quit, a SIGTERM should be generated? It doesn't trigger the on_unix_signal(), whereas hitting Control-C does. I think for now, I am going to regard auto-saving widget states as unreliable. Instead, I will keep anything that ought to be saved in vars, which don't disappear on me. On 3/3/13, Michael Haberler wrote: > > Am 03.03.2013 um 13:45 schrieb andy pugh: > >> On 3 March 2013 07:39, Michael Haberler wrote: >> >>> 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. >> >> This is considering the process that happens when LinuxCNC is exited >> with a machine powered-up and running? I can see this is a type of >> e-stop, but not the normal sort. > > Right > >> Is it possible to refuse to quit until at least one servo cycle has >> run with the LinuxCNC enable outputs disabled? > > the current sequence is in scripts/linuxcnc function Cleanup: > > it sends signals to all user processes (UI, task etc) ; first SIGTERM, later > SIGKILL if a process wont exit > then it stops the realtime threads via halcmd stop > then it proceeds to unload hal_lib, rtapi and modules and cleans up > > If anything happens before threads are stopped really depends on what user > processes are doing and if/how they react to a signal > > what I was referring to: if you react to the shutdown signal (or a segfault > for that matter) in one of the user processes, that potentially reduces the > time window until threads are stopped, and there is some choice what still > can be done - provided safe signal programming techniques are used > > I'd need to look if any components actually react in HAL due to a signal > directly; cant remember having seen it > > -m > > > -- > 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 > -- 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
Re: [Emc-users] GladeVCP Persistence On_Destroy sensitivity
Am 03.03.2013 um 13:45 schrieb andy pugh: > On 3 March 2013 07:39, Michael Haberler wrote: > >> 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. > > This is considering the process that happens when LinuxCNC is exited > with a machine powered-up and running? I can see this is a type of > e-stop, but not the normal sort. Right > Is it possible to refuse to quit until at least one servo cycle has > run with the LinuxCNC enable outputs disabled? the current sequence is in scripts/linuxcnc function Cleanup: it sends signals to all user processes (UI, task etc) ; first SIGTERM, later SIGKILL if a process wont exit then it stops the realtime threads via halcmd stop then it proceeds to unload hal_lib, rtapi and modules and cleans up If anything happens before threads are stopped really depends on what user processes are doing and if/how they react to a signal what I was referring to: if you react to the shutdown signal (or a segfault for that matter) in one of the user processes, that potentially reduces the time window until threads are stopped, and there is some choice what still can be done - provided safe signal programming techniques are used I'd need to look if any components actually react in HAL due to a signal directly; cant remember having seen it -m -- 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
Re: [Emc-users] GladeVCP Persistence On_Destroy sensitivity
On 3 March 2013 07:39, Michael Haberler wrote: > 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. This is considering the process that happens when LinuxCNC is exited with a machine powered-up and running? I can see this is a type of e-stop, but not the normal sort. Is it possible to refuse to quit until at least one servo cycle has run with the LinuxCNC enable outputs disabled? (is that what happens at the moment?) -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- 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
Re: [Emc-users] GladeVCP Persistence On_Destroy sensitivity
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
Re: [Emc-users] GladeVCP Persistence On_Destroy sensitivity
Am 03.03.2013 um 03:46 schrieb Kip Shaffer: > Anybody using GladeVCP with Persistence? Did you have trouble getting > it to save settings? > > It seems to me as though it is very sensitive to what widget the > 'on_destroy' signal is attached. > > The documentation does warn against attaching it to the 'window1' > object. But I had terrible luck getting it to save_state when > LinuxCNC was shutting down. me too, and I wrote that code ;) unfortunately there is more than one way to shut down a gladevcp application: - you can kill the window which will get you a destroy event - the linuxcnc script however sends a signal to all running parties to catch the second scenario, see http://www.linuxcnc.org/docs/devel/html/gui/gladevcp.html#_saving_state_when_ctrl_c_is_pressed > > I was able to figure out what it was trying to do by putting print > statements into > /usr/lib/pymodules/python2.6/gladevcp/persistence.py > > What I found was that the getter() returned by get_value() would fail > when the window was being destroyed. yes, it's a chicken-and-egg problem - persistence.py cant do anything anymore if it is called too late in the shutdown process (eg if the widgets are already destroyed there's no way to retrieve their state anymore) let me know how it goes - Michael > > I resolved the problem by putting the 'on_destroy' signal on the same > widget that was being read first. There is no way to determine which > widget will be first, other than by putting in print statements. > > Has anyone else seen this behavior? > > -Kip > > -- > 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 -- 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
[Emc-users] GladeVCP Persistence On_Destroy sensitivity
Anybody using GladeVCP with Persistence? Did you have trouble getting it to save settings? It seems to me as though it is very sensitive to what widget the 'on_destroy' signal is attached. The documentation does warn against attaching it to the 'window1' object. But I had terrible luck getting it to save_state when LinuxCNC was shutting down. I was able to figure out what it was trying to do by putting print statements into /usr/lib/pymodules/python2.6/gladevcp/persistence.py What I found was that the getter() returned by get_value() would fail when the window was being destroyed. I resolved the problem by putting the 'on_destroy' signal on the same widget that was being read first. There is no way to determine which widget will be first, other than by putting in print statements. Has anyone else seen this behavior? -Kip -- 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
