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 <[email protected]> wrote:
>>
>> Am 03.03.2013 um 13:45 schrieb andy pugh:
>>
>>> On 3 March 2013 07:39, Michael Haberler <[email protected]> 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
>> [email protected]
>> 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
> [email protected]
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-users
