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.ash...@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.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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
