[fpc-pascal]Signals revisited

[Michael Van Canneyt]

On Thu, 2 Nov 2000, md wrote:

> Michael:
> 
> I am still trying to get a grip on signals:
> 
> 
> There are three classes of signals as I know them to be:
> 
> Fatal Signals  involving core dump
> 
> Mild Signals  requesting application supported shutdown
> 
> Who cares Signals - Ignore them, they do not apply
> 
> 
> The fatal signals include:
> 
> SIGSEGV, SIGFPE, SIGILL, and SIGTRAP.
> 
> The mild signals include:
> 
> SIGINT
> SIGQUIT
> SIGABRT   
> SIGBUS    
> SIGSEGV   
> SIGTERM   
> SIGPWR  
> 
> Who cares signals include:
> 
> SIGHUP
> SIGUSR1   
> SIGUSR2   
> SIGPIPE   
> SIGALRM   
> SIGSTKFLT 
> SIGCHLD   
> SIGCONT   
> SIGTSTP   
> SIGTTIN   
> SIGTTOU   
> SIGURG    
> SIGXCPU   
> SIGXFSZ   
> SIGVTALRM 
> SIGPROF   
> SIGWINCH  
> SIGIO     
> 
> The Fatal signals I just don't even handle.

Why ? The SIGSEGV can be caught.

> The Mild signals I install a handler for them, but I do not raise the 
> signal again after handling the signal.

Seems OK.

> 
> I am assuming the behavior of the system after the handler not raising(
> ) another signal 
> is to proceed as normal.

Yes, I suppose so.

> 
> Or should I try to do shutdown activities within the context of the
> signal handler?

This depends; the SIGTERM is usually sent to a program telling it
that it should stop operations. you should then really shut down
the program in a gentle way.

> 
> Again, it is the implementation in handling these signals without
> causing exception violations is the key.

Yes; you must of course be careful.

> 
> What happens to the executing context of the process when a signal is
> raised. Does that process go idle in the kernel while he handler
> executes?

No; the 'executing context' is the signal handler at that time; when the
handler returns, operation is resumed as normal, I think.

Michael.
> 
> Your response appreciated.
> 
> Mark Diener
> 
> 
> 
> Michael.VanCanneyt at wisa.be wrote:
> > 
> > On Wed, 1 Nov 2000, md wrote:
> > 
> > > I guess you are in Belgium somewhere.  Maybe Brussels?
> > 
> > About 25 Km. east of Brussels, to be exact.
> > 
> > >
> > > This signal stuff is excellent white paper material.
> > 
> > Indeed.
> > 
> > >
> > > Some "mysteries of signals" lifted.
> > >
> > > >From your response, I am assuming that I cannot reinstall the handler
> > > while inside the handler.
> > 
> > No, you can, and most signal handlers do this as the first thing, to be
> > able to trap the error if it should occur again.
> > 
> > >
> > > To continue default behavior, I must raise( ) the signal again and
> > > default core dumping
> > > and terminating will take place.
> > 
> > yes. Only you should use sigraise(), not raise()
> > 
> > >
> > > Only for the stop signal must I raise an SIGCONT signal.
> > 
> > If you want to continue execution, yes.
> > 
> > >
> > > >From what I conclude, I can handle the signal then Raise it again and
> > > the default processing
> > > would take place.  If I do not raise it again, the default processing
> > > will not take place.
> > 
> > Correct.
> > 
> > >
> > > Please confirm these statements.
> > 
> > Request fulfilled, I hope...
> > 
> > Michael.
> > >
> > > Mark Diener
> > >
> > > Michael.VanCanneyt at wisa.be wrote:
> > > >
> > > > On Wed, 1 Nov 2000, md wrote:
> > > >
> > > > > Please ignore my earlier posting on signals.
> > > > >
> > > > > I have found an explanation of many signals at the following web
> > > > > address:
> > > > >
> > > > > http://step.polymtl.ca/~ldd/syscalls/syscalls_99.html
> > > >
> > > > I will add this list to the documentation, as it may be useful.
> > > >
> > > > >
> > > > > Notice on the web page it refers to
> > > > > "terminates" and "stops" in parentheses.
> > > > > What do you think that means?
> > > >
> > > > It refers to the behaviour if the signal is not caught. i.e. if the signal
> > > > SIGHUP is not caught, the program will be terminated.
> > > >
> > > > >
> > > > > Are there signal handlers that actually freeze the process and how do we
> > > > > override this
> > > > > behavior if it is true.  Every process should keep executing regardless
> > > > > of signal handled.
> > > >
> > > > The KILL signal will terminate the process. There is no way to stop this,
> > > > as this signal cannot be caught.
> > > >
> > > > The STOP signal will freeze the process till it gets a 'CONTINUE' signal.
> > > > This cannot be stopped either, AFAIK.
> > > >
> > > > All other signals can be caught and should be caught if they can appear in
> > > > your program.
> > > >
> > > > >
> > > > > What is still unclear is how to have a signal handle perform internal
> > > > > processing
> > > > > and still allow for system default core dumping and process termination.
> > > >
> > > > By default, the signal handler is uninstalled when it is called. You can
> > > > 1) Not reinstall it in the handler.
> > > > 2) send the same signal again to yourself.
> > > > (both steps must be done)
> > > >
> > > > then you'll get the default behaviour. This should only be done for signals
> > > > that can generate a core dump.
> > > >
> > > > Michael.
> > > > >
> > > > > The core dump is helpful for debugging purposes.
> > > > >
> > > > > Any help appreciated,
> > > > >
> > > > > Mark
> > > > >
> > > > >
> > > > > Michael.VanCanneyt at wisa.be wrote:
> > > > > >
> > > > > > On Tue, 31 Oct 2000, md wrote:
> > > > > >
> > > > > > > FPC developers:
> > > > > > >
> > > > > > > Here is a brain teaser.
> > > > > > >
> > > > > > > Let us say we have two environments:
> > > > > > >
> > > > > > > 1) Normal BASH shell with prompt in TTY1 -  The TERM environment
> > > > > > > variable will be set to linux
> > > > > > > 2) KDE Destktop - The TERM environment variable will be set to xterm
> > > > > > >
> > > > > > > Under the non-x window environment, how do we fork() / execlp( ) another
> > > > > > > process so that the new child process
> > > > > > > will use a different Ttty console to output its writeln( ) information
> > > > > > > to.
> > > > > > >
> > > > > > > Under KDE, I can execute a fork() with execlp( ) and the command line
> > > > > > > will be as follows 'konsole -e /bin/application arg1'
> > > > > > >
> > > > > > > The net effect of this is that the parent process continues in its own
> > > > > > > console window and the child process will execute
> > > > > > > in a separte console window. The input/output of each process is now
> > > > > > > separate to each window.
> > > > > > >
> > > > > > > Under non-xwindows environments, .i.e. normal bash shell, How do we
> > > > > > > fork() / exec( ) a process so that it will be assigned a different TTY
> > > > > > > or some other means of having a separate console for each process.
> > > > > >
> > > > > > under bash, one would type:
> > > > > >
> > > > > > command args >/dev/ttyX 2>&1 </dev/ttyX &
> > > > > >
> > > > > > or under csh
> > > > > >
> > > > > > command args >& /dev/ttyX </dev/ttyX
> > > > > >
> > > > > > (replace X with the terminal number)
> > > > > >
> > > > > > The /dev/ files need the correct permissions, of course.
> > > > > >
> > > > > > under FPC you would do the following;
> > > > > >
> > > > > >   fork
> > > > > >   if pid=0 then
> > > > > >      // Child
> > > > > >     begin
> > > > > >     // Same effect as below may be gotten with dup2() !!
> > > > > >     Close(input);
> > > > > >     Close(output);
> > > > > >     Close(stderr);
> > > > > >     Assign(Input,'/dev/ttyx');
> > > > > >     Assign(output,'/dev/ttyx');
> > > > > >     Assign(stderr,'/dev/ttyz');
> > > > > >     Reset(input);
> > > > > >     Rewrite(output);
> > > > > >     Rewrite(stderr);
> > > > > >     Execlp('command','args')
> > > > > >     end
> > > > > >   else
> > > > > >     begin
> > > > > >     // Parent
> > > > > >
> > > > > >     end;
> > > > > >
> > > > > > >
> > > > > > > What this also means that the login process for a given TTY is skipped
> > > > > > > or avoided so the processes that are started from
> > > > > > > the runlevel 3 inittab file can spawn processes that will take over a
> > > > > > > given console.
> > > > > >
> > > > > > You'd better do that, yes.
> > > > > >
> > > > > > >
> > > > > > > This is different that just logging into a bunch of different consoles
> > > > > > > and running each process on a given console.  This is where the code is
> > > > > > > assigning processes to consoles.
> > > > > > >
> > > > > > > Any help would be appreciated.
> > > > > >
> > > > > > I hope the above helps.
> > > > > >
> > > > > > Michael.
> > > > > >
> > > > > > _______________________________________________
> > > > > > fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> > > > > > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> > > > >
> > > > > _______________________________________________
> > > > > fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> > > > > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> > > > >
> > > >
> > > > _______________________________________________
> > > > fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> > > > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> > >
> > > _______________________________________________
> > > fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> > > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> > >
> > 
> > _______________________________________________
> > fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> 
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
>