Not too difficult, actually.  The work of raising a halt condition is
eventually performed in RexxActivity::halt, which can already take a
description string.  The path to get there is
Interpreter::haltAllActivities->InterpreterInstance::haltAllActivities->RexActivity::halt.
 The first two calls don't take an argument, so you'd need to add one and
pass it along to halt.

There is a complication here.  The interrupt handler happens asynchronously
and in a state where it is not safe to create new objects.  This means any
strings passed along as the description will need to be added to the global
interpreter string table (e.g., one of the OREF_* names).  This means
adding appropriate entries in GlobalNames.h and RexxConstants.hpp.  The
need to add this in both places is an old vestiage of IBM standards carried
to the ultimate extreme.  I would not object strenuously if this was done
by just coding the literal string value directly in GlobalNames.h without
adding a corresponding CHAR_* entry to RexxConstants.hpp.  I've sort of
already been doing that sort of thing in Setup.cpp when adding new method
names.

Rick


On Thu, Nov 15, 2012 at 10:51 AM, David Ashley <w.david.ash...@gmail.com>wrote:

> Rick -
>
> I need you help with this code.
>
> If all these signals are going to raise the Halt condition, we need to
> supply the user with additional information about what kind of signal
> this is. How do I add additional information about the kind of Halt
> (signal) that was raised?
>
> 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.
> >
> >
> >
>
>
>
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to