I was suggesting a change to haltAllActivities.  Note that this will also require a couple of tweaks to the Windows-specific code as well. 

Rick


On Mon, Nov 26, 2012 at 12:02 PM, David Ashley <w.david.ashley@gmail.com> wrote:
I have looked into your reply below and I have a question.

Would you prefer me to change the existing haltAllActivities methods or
create new ones with a different argument footproint?

Either works for me, this is just a style question really.

David Ashley

On Thu, 2012-11-15 at 11:20 -0500, Rick McGuire wrote:
> 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.ashley@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.ashley@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



------------------------------------------------------------------------------
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