> When a process receives a SIGHUP the terminal is already dead. > Therefore, if we let the script intercept this signal we give > it the ability to attempt console I/O during the processing > of the signal. If that happens the process will hang. This > produces what is sometime known as a zombie process. The > process will remain active until it receives a SIGKILL or a > SIGTERM (there may be other signals that can force > termination but these are the most common). And if we > intercept the SIGTERM signal even then we may have the > console I/O problem again. > > Casual users could get bitten by this "feature" without their > knowledge. > Even some programmers could be bitten. Signal processing is a > non-trivial topic. We have to compromise on this because > giving too much control can be just as bad as not giving enough. > > My opinion is that we should make no attempt to process a > SIGHUP except to safely terminate the script. No control > should be handed over to the user for this signal. If they > want processing to continue after a SIGHUP then they should > use the "nohup" command to force that kind of processing. > Using the "nohup" command will cause the system to not send > the SIGHUP signal to the process when the terminal goes away.
If the problem is 'the terminal' could not Rexx simply disable output to it once SIGHUP is received? Pretty odd to stop programs closing files, etc., just because the teminal went away (perhaps due to a network breakage)? In short: make the programming easier (and less system-dependent on oddities like this) rather than forcing the programmer -- and all their users -- to learn about "nohup" in order to get their program to run safely under *ix. Mike ------------------------------------------------------------------------------ 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
