Re: [Oorexx-devel] Intercepting kill command
I have been giving this some thought and I would like to discuss this
further before we implement these changes.
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.
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
Re: [Oorexx-devel] Intercepting kill command
I agree with you. SIGHUP, is still under the users control. If they want the
program to continue processing after a SIGHUP, they can always start the
program with the nohup command. I think that this would be the expected
behavior.
Bruce
Sent from an undisclosed location.
On Nov 9, 2012, at 7:17 AM, 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.
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.
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
--
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
[Oorexx-devel] Fwd: ApacheCon Europe Talk Scripting Apache OpenOffice with ooRexx ...
Original Message Subject:ApacheCon Europe Talk Scripting Apache OpenOffice with ooRexx ... Date: Fri, 09 Nov 2012 16:55:10 +0100 From: Rony G. Flatscher rony.flatsc...@wu-wien.ac.at To: RexxLA Members mailing list rexxla-memb...@mail.rexxla.org Hi there, just came back from this week's ApacheCon Europe 2012 conference where I presented a talk about Scripting Apache OpenOffice (Thursday after lunch, cf. http://www.apachecon.eu/schedule/). The slides and the nutshell examples can be found here:http://wi.wu.ac.at/rgf/rexx/misc/ApacheConEurope12/. The presentation gives a bird eye's view of OpenOffice and shows with nutshell examples (written in ooRexx taking advantage of BSF4ooRexx) how to script the AOO wordprocessor, the AOO spreadsheet and the AOO presentation program. If you have questions about the presentation or the nutshell examples, then please come forward with them. ---rony -- 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
