On Fri, 09 Nov 2012 09:17:04 -0600
David Ashley <w.david.ash...@gmail.com> wrote:
> I have been giving this some thought and I would like to discuss this
> further before we implement these changes.
>
Yep, I agree.
> I believe there is a basic difference between the SIGTERM and SIGHUP
> signals and the way they should be processed. While I do not have a
> problem with SIGTERM being handled by the script I have a fundamental
> problem with handing the SIGHUP off to the user's script. I believe
> this should be caught by the interpreter and handled internally so
> that a forced, but graceful, program termination is performed i.e.
> the program is never handed a SIGHUP signal. The reason for this is
> that when a SIGHUP arrives it means that the program should end, and
> end quickly. Giving the user control could mean that the program is
> NEVER terminated because the the user forces some kind of additional
> endless processing.
>
It could happen with a SIGINT or SIGTERM as well that some endless
processing arises due to a programming mistake or whatever.
If I've started a rexx script on the command line then when pressing
Ctrl-C (--> SIGINT) I want the script to stop immediately. Therefore it
is important that the script has a chance to do some cleanup processing
if required. Regarding SIGINT we both agree. SIGTERM (provoked by kill
-s SIGTERM) is the same thing.
Let us look at SIGHUP. Assume I started a rexx script via something
like xterm -e rexx myscript.rex. The user who (used to act with a
mouse) wants to stop it normally clicks on the X-button (which is the
same as the Close item in the windows menu). Then IMHO the script
should also have a chance to do cleanup processing if it is needed. In
a way clicking the X-button is analogeous to Ctrl-C in a shell where I
only want to stop the rexx script.
I would even go as far and say we should allow all external
termination signals to be trapped by SIGNAL ON HALT as Chip has
described it nicely. I fully!! agree with his thoughts.
If we would agree upon 'trapping all signals' then of course, we would
have to define what 'all' means as SIGKILL won't work and perhaps some
other signal won't make sense to trap.
--
Manfred
> Do other have comments on this?
>
> David Ashley
>
> On Tue, 2012-11-06 at 16:40 +0100, Manfred Lotz wrote:
> > On Wed, 31 Oct 2012 08:39:53 -0500
> > David Ashley <w.david.ash...@gmail.com> wrote:
> >
> > > Rick will need to comment on this. I am not an expert in the
> > > interpreter code base.
> > >
> >
> > Ok, I had a deeper look at this. Here is a small test script which
> > could be used to verify my coding:
> >
> > /* REXX */
> >
> > signal on halt
> >
> > file=.stream~new("sig.lst")
> > pull
> > file~close()
> >
> > exit(0);
> >
> > halt:
> > msg = "Signal on halt reached."
> > file~lineout(date() time() msg) /* Append a line to the file */
> > file~close()
> >
> >
> > The script writes a message if signal on halt hits.
> >
> >
> > Take the current 4.1.2 rexx interpreter and run it. There are three
> > test cases.
> >
> > 1. rexx sigtest.rexx
> >
> > Press Ctrl-C. This triggers SIGINT, and is already implemented in
> > rexx. A record will be written to file sig.lst
> >
> > 2. rexx sigest.rexx
> > Get the pid of the process and do kill <pid>. This triggers signal
> > SIGTERM.
> >
> > Not implemented in rexx. No record written.
> >
> > 3. xterm -e rexx sigtest.rexx
> > a. Now click the x button to close the window. This triggers signal
> > SIGHUP. Not implemented in rexx, no record written.
> > b. Check for the pids of the two processes, i.e. xterm and rexx.
> > Kill the one or the other by using ordinary kill. In neither case a
> > record will be written.
> >
> >
> > I think that additionally SIGTERM and SIGHUP should be trapped by
> > signal on halt. Then in these cases rexx has a chance to do cleanup
> > work before exiting the script.
> >
> >
> > Here is what must be changed so that all above examples result in a
> > record written, i.e. signal on halt will honor SIGTERM and SIGHUP
> > (additionally to SIGINT).
> >
> > Index: interpreter/platform/unix/SystemInterpreter.cpp
> > ===================================================================
> > --- interpreter/platform/unix/SystemInterpreter.cpp (revision
> > 8547)
> > +++ interpreter/platform/unix/SystemInterpreter.cpp (working
> > copy)
> > @@ -101,7 +101,9 @@
> > #endif
> >
> > // if the signal is a ctrl-C, we perform a halt operation
> > - if (sig == SIGINT)
> > + if (sig == SIGINT ||
> > + sig == SIGTERM ||
> > + sig == SIGHUP)
> > {
> > Interpreter::haltAllActivities();
> > return;
> > @@ -132,9 +134,13 @@
> > /* that we now get a coredump instead of a hang
> > up */
> >
> > sigaction(SIGINT, NULL, &old_action);
> > + sigaction(SIGTERM, NULL, &old_action);
> > + sigaction(SIGHUP, NULL, &old_action);
> > if (old_action.sa_handler == NULL) /* not set by ext.
> > exit handler*/
> > {
> > - sigaction(SIGINT, &new_action, NULL); /* exitClear on
> > SIGTERM signal */
> > + sigaction(SIGINT, &new_action, NULL); /* exitClear on
> > SIGINT signal */
> > + sigaction(SIGTERM, &new_action, NULL); /* exitClear on
> > SIGTERM signal */
> > + sigaction(SIGHUP, &new_action, NULL); /* exitClear on
> > SIGHUP signal */
> > }
> > }
> >
> >
> >
> > What do you thing? Please check the code. Thanks a lot.
> >
> >
> >
>
>
>
> ------------------------------------------------------------------------------
> 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_nov
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
--
Manfred
------------------------------------------------------------------------------
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_nov
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
